Many drivers are appearing in user space anyway, often with truly token
kernel support. Examples
- XFree86 (uses mmap and user space dma)
- SANE (uses scsi generic, perhaps ide-scsi emulation)
- cdrecord (uses scsi generic, perhaps ide-scsi emulation)
- ghostscript (de-facto printer drivers)
Locking the kernel interfaces down won't help any company coding binary
only drivers for any of these projects.
My point: the "problem" is much broader than just the kernel. You can't
save the world by locking down the Linux kernel driver interfaces.
> OK, so we don't want to lock down interfaces forever. I can accept
> that. But do we really need to allow interfaces to arbitrarily change
> during a stable kernel series? (Most of the times when we've need to
> make such major changes to the stable kernel series, particularly during
> the 2.0 series, stability has suffered.) I'd claim that it really isn't
> that difficult to lock down internal interfaces during a stable kernel
> release, and allow manufacturers to release device drivers that work
> against 2.2 kernels. If they need to rewrite their drivers for the 2.4
> kernels, fine.
Every stability issue I've ever had with Linux has been traced to a bug
in a driver. Binary only drivers would have meant adding kludges to the
kernel to work around bugs in the drivers. No thanks. I want source for
my driver, and if I have source, there's no problem changing interfaces
and recompiling (someone will know how it's done).
My point: there's no such thing as a "stable kernel release" if drivers
are available only in binary form. Drivers Needs Source.
ObReligiousArgument: whether everything needs source or not isn't worth
arguing about, but drivers are too valuable to be binary only.
-- Nathan Hand - Chirp Web Design - http://www.chirp.com.au/ - $e^{i\pi}+1 = 0$ Phone: +61 2 6230 1871 Fax: +61 2 6230 1515 E-mail: nathanh@chirp.com.au- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/