Quote:> I just started on a project to develop PCI and ISA drivers for a
> variety of computer telephony DSP cards. There have been substantial
> changes in the PCI access functions since 2.0. Therefore, we had to
> make a decision whether to have a lot of conditional compilation code
> or limit our driver to support a given set of kernel releases.
There are always tradeoffs. The obvious alternatives:
* Not develop as fast. Sorry....
* Develop as now but never make incompatible changes. Unfortunately
everyone's hands are forever tied by bad design decisions, and no old
stuff can ever get "cleaned up". This is a problem the Microsoft OS
groups are always having to face and nobody envies them for it.
* Define a "compatibility layer" either now or whenever something
changes, which is more or less guaranteed *not* to change. This is
what libc provides (so that, for example, if the pre-2.2 version of
the `umount' system call is ever dropped, programs that use it will
still run fine so long as a semi-recent libc is installed). The idea
here is that the libc layer would have a kernel-mode equivalent.
Linus is adamantly opposed to this, though. He believes that such a
layer is needlessly inefficient, complex at the source level, and
still ends up tying your hands.
Quote:> The rapid ongoing of Linux is a mixed blessing. Great for people who
> need support for more and more devices, a pain for those folks
> actually providing the driver code.
Unless you're someone like Cyclades, who contributes their own drivers
to the stock kernel tree where they tend to get updated whenever major
interface changes come down the pipe. And then, although they provide
most of the driver updates, at least they don't have to worry about
providing their customers with the "correct" version of the driver --
it's in the "correct" source tree already.
Quote:> Yes, I know a lot of Linux developers will take exception to this,
> but this 'feature' could cause longterm problems in having hardware
> developers providing Linux support for their boards.
Note that the issue at hand was not source-level compatibility (like
the PCI BIOS stuff you mentioned) but binary compatibility.
Source-level compatibility is actually quite good within a given stable
release cycle (like 2.0.* or 2.2.*). However, *binary* compatibility
is not, so if you're reticent about giving out your driver source, you
have to compile for individual releases and SMP/non-SMP. The AFS
people complain about this occasionally.