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:[EMAIL PROTECTED] Sent: Monday, September 11, 2000 9:03 PM To: Howell, David P Cc: [EMAIL PROTECTED]; 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
