RE: Modules Standard, extended to kernel code
I can see that this has been kicked around already, so I won't take it
further that this response.
It's a reality that real applications sometimes include drivers and other
kernel code, which occasionally (just like APPs) have code that a vendor
doesn't want distributed in the public domain and so won't provide source
code; I can't see much of a difference in how this case should be handled
vs APPs, and I'm kinda confused why there would be such a distinction made
here. Doesn't seem realistic.
As for the kernel driver interfaces, if a standard defined a abstraction
layer (aka DDI/DKI) for developers concerned with portability and left
the driver internal interfaces and implementation to the architects, that
would work.
-----Original Message-----
From: Dan Kegel [mailto:dank@alumni.caltech.edu]
Sent: Monday, September 11, 2000 9:03 PM
To: Howell, David P
Cc: lsb-discuss@lists.linuxbase.org; Smith, Stanley W; Davis, Todd C;
Vollbrecht, Randy P
Subject: Re: Modules Standard, extended to kernel code
"Howell, David P" wrote:
> To add in my 2 cents, specifically is there a standard planned or in the
> works for loadable or statically linked in kernel drivers and subsystems?
> I'm new here but come from a System 5/SVR4 background where there was a
> DDI/DKI standard for drivers that defined a set of kernel interfaces that
> a driver writer could assume was always going to be there in a kernel,
> with the same semantics across different architectures.
Nope. Linus has specifically reserved the right to modify the kernel
interface periodically -- but modules whose source is in the public kernel
source tree will be updated to match the new interface by whoever
implements the kernel interface change. This is a win for driver
developers, as it means they get the benefits of interface updates
and fixes without lifting a finger. Or so the theory goes.
This lets Linus and his minions clean up the interface when they
discover it's gotten crufty, or update it when they discover it
lacks an important feature.
> Here at Intel we ran into an issue with a driver that is produced
> by an Intel group being useful for only one release of a distribution
> (i.e. Red Hat 6.2) but could not be used with the previous point
> release (6.1) due to module versioning.
Was the source to the driver released under the GPL and sent to
the linux kernel maintainers? That's the only real way to ensure
that kernel maintainers can provide backports when needed.
- Dan
Reply to: