There is a lot of code which is rarely used in the kernel. Around 2.6.8-2.6.9 I needed a
driver (ArcNet) which clearly hadn't been used since some time in 2.5. But I fixed the bug,
submitted a patch and later on at least one other person have fixed a bug in the driver, and I
see a few janitory changes around.
Clearly not many people are using this driver. But because it was still in the mainline kernel
it was keeped up-to-date wrt. interface changes and compile-tested. It was untested and
contained a bug, which was fairly simple to fix. If the driver wasn't in the mainline, I am
pretty sure I would never had got around to get ArcNet to work in Linux at all, since it was
only a "private" experiment at my former job.
I can't see why a file system should be different.
The only other way to make sure Linux supports a lot of old stuff, is to make a stable API and
be backward compatible. But how easy would it be to make it possible to (compile and) load a
2.4 driver into a 2.6 kernel with no modifications?
I am not even sure a "micro kernel" (like using fuse) approach would help much. The interfaces
might be much more stable, but over a long period they will be changed. But will they get
compiled checked as they are in Linux now?
Posted Apr 17, 2008 11:05 UTC (Thu) by mszeredi (subscriber, #19041)
[Link]
Backward compatibility in fuse is guaranteed on multiple levels:
- the raw kernel interface
- the library ABI
- the library API
While new major versions of the library might come out in the future, the old versions will
still be usable. Just like gtk-1.2 libraries are still around in distributions, many years
after gtk-2.0 has been released.
I agree though, that in case of drivers where a userspace soultion is not available, keeping
support for old hardware in the kernel is a good thing.