LWN: Comments on "Kernel Summit: The customer panel"

Re: Multipath support?

roelofs — Wed, 28 Jul 2004 03:34:01 +0000

Multipath what? Does this refer to multipath block devices of the sort mentioned at http://oss.software.ibm.com/linux390/useful_add-ons_lvm.shtml?

Apparently so--everything from dual 1394/USB2 external drive enclosures on up to unspecified monster arrays costing major $$$.

Greg

driver interface stability

mdomsch — Tue, 27 Jul 2004 13:53:05 +0000

> 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.

driver interface stability

giraffedata — Fri, 23 Jul 2004 22:55:21 +0000

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.

Disaster Recovery

robertpostill — Fri, 23 Jul 2004 08:19:44 +0000

I used to work for a DR company that had fledgling support for Linux. It was rock. As a previous poster mentioned life gets difficult if you have a kernel and need to splice a driver onto that kernel. For instance, the DR company had HP servers, the idea being that the technicians each had to learn only one hardware platform. If a customer had Dell or IBM kit then the number one problem was getting their RAID array into the kernel. As most operations did not have a seperate boot disk, the root would often need to be supplyed through RAID. Dependant on their implementation you'd have to either:
a) Do a re-install of the OS on the new box and use the drivers etc. supplied with that.
b) Install on a similar box, pinch or compile driver, remake initrd, bodge /boot and possibly root fs to hold drivers.
I can't begin to describe how simple that is with a customer behind you going spare that their Oracle DB isn't coming back :)
Now don't get me wrong, it's as nasty for windows, just quicker, because the drivers are already compiled for you and its the time that DR customers care about.

All in all initiatives like dkms and a stabilisation of the driver API would be welcome in the corporate world and I'm glad the kernel summit is exposing these issues.

Multipath support?

GreyWizard — Thu, 22 Jul 2004 21:54:13 +0000

Multipath what? Does this refer to multipath block devices of the sort mentioned at http://oss.software.ibm.com/linux390/useful_add-ons_lvm.shtml? Or something else?

driver interface stability - use DKMS

mdomsch — Thu, 22 Jul 2004 02:51:42 +0000

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.
-Matt Domsch

driver interface stability

elanthis — Wed, 21 Jul 2004 13:40:55 +0000

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.