| |||||||||||||
driver interface stabilitydriver interface stabilityPosted Jul 21, 2004 13:40 UTC (Wed) by elanthis (guest, #6227)Parent article: Kernel Summit: The customer panel Putting drivers in the kernel does *NOT* fix the actual problem. Even with GPL drivers, the interface instability makes some serious pain for users. Currently, if you want to use a new piece of hardware that didn't have a driver in the kernel at the time your OS was put together, you need to upgrade your kernel. That can be a *serious* PITA, especially when you already have a customized kernel. Getting a new kernel built, tested, and installed properly can be a big undertaking, and that's for a very experienced Linux user; Mom 'n' Pop are never going to be able to handle it. Vendors generally don't release new kernels for older distros solely for the sake of new drivers, either, because of all the time and QA problems listed above. You also run into the problem where a driver is needed during install. In this case, you not only have to make a custom kernel, but manage to get it usable during install as well, usually by making a customized boot disk. It's a total and complete PITA. At least having a stable API would make it possible for users to download and compile drivers (hopefully with a nice GUI to automatically do the work; even if you know how, why should you have to waste the time doing it manually when it's avoidable?) and have them Just Work(tm) with no kernel updates or other dangerous/difficult operations. You can't even do this with GPL drivers right now. Having a stable ABI would make it possible for hardware vendors to put Linux drivers on media with the hardware for use during installation. Again, even if the drivers _are_ GPL, they can't do this currently.
(Log in to post comments)
driver interface stability - use DKMS Posted Jul 22, 2004 2:51 UTC (Thu) by mdomsch (subscriber, #5920) [Link] Shameless plug: http://linux.dell.com/dkms/
DKMS does what you're looking for, and if not exactly, we'll gladly review and accept patches.
driver interface stability Posted Jul 23, 2004 22:55 UTC (Fri) by giraffedata (subscriber, #1954) [Link] So I think you're saying that including a device driver in the Linux kernel solves the problem of future API changes, but doesn't solve the problem of past API changes. I.e. a device vendor who ships a driver for today's Linux would be shielded from any incompatibility with tomorrow's Linux, but there still wouldn't be any drivers for yesterday's Linux.People usually think of the API problem as being one of future API changes, since there's nothing a device vendor can do about those, whereas the vendor could, if he really wanted to, ship drivers for past versions of the API. But I suppose the fact that vendors don't take the trouble to ship drivers that work with all historical Linuxes is also a good reason never to change (incompatibly) the API.
driver interface stability Posted Jul 27, 2004 13:53 UTC (Tue) by mdomsch (subscriber, #5920) [Link] > But I suppose the fact that vendors don't take the trouble > to ship drivers that work with all historical Linuxes is > also a good reason never to change (incompatibly) the API.Hardly. That would suggest that because people outside our sphere of influence (they're not in the kernel) don't do work with the kernel, that they should have significant influence on kernel design and development (freezing the APIs). That way lies madness. The kernel (through kcompat.h) and projects like DKMS make it easier for vendors to backport their work to earlier kernels, even those with different APIs than the current kernels. Also, it's a matter of timing. If drivers are merged in early enough, then there's less need to do backports, yes? That can't always happen (new hardware does become available, and users of that hardware want support on historical kernels), so good programming practices like kcompat.h and DKMS can help vendors there too.
|
|||||||||||||