For the kernel you can write one. Go ahead. Its not trivial. Consider the
real cases where fixes had to be done. How do you back compatibly fix a
70K packet size into a 16bit length field ?
The cases where its trivial are ones it shouldnt have occured.
Such as the time when we reordered structure elements during the Linux
2.0 release?
To an outside developer, "we reordered the structure order to make
things a little faster because of cache alignment" sounds suspiciously
like the lame excuses Microsoft gives for making technical changes that
break competitors' code. Sure, they claim that they're doing it for
"technical reasons", but everyone knows they did it to screw their
competition, even if the DOJ has trouble proving it. Let's not stoop to
that level, shall we?
Stepping back to the bigger picture, the point I hope is clear. We need
to be much more careful during the 2.2 series to minimize interface
changes as much as possible. This includes device driver authors, who
need to make sure they don't disturb ioctl interfaces. (When I design
my ioctl interfaces, I include padding structure elements so that I can
later add new fields to the structure without changing the structure
size. This isn't hard; it just requires a little extra forethought.)
I believe it should include trying to stablize the binary kernel module
interface as well; I personally believe this interface doesn't have to
be as stable, but every other 2.2 release shouldn't be gratuitously
breaking the binary module interface.
For user space glibc should be compatible. The LSB standards base project
is also a _binary_ standard. It documents API behaviour but for binary
compatibility. Glibc also split from the kernel headers to keep stability.
The LSB standards base product is a good start, but we kernel developers
have to do our part, too. This means doing things like planning ahead
with structure sizes, using new ioctl numbers to provide compatibility
when we *do* need to change the structure sizes, and so on.
If you want to make this work even better run a lot of 2.0 binaries
on 2.2, check they all still work. If not find out why. Similarly
people should be trying stuff like glibc 2.1 pre-releases with all
their old binaries. Nothing should break, if it does report it.
Well, note that we have an problem soon to face us when glibc 2.1 gets
released, since they changed the FILE structure. While symbol
versioning helps to solve this problem somewhat, it doesn't help if the
API's for shared libraries include FILE pointers, since the symbol
versioning won't catch this case. This may mean that we as the Linux
community might want to decide to defer taking glibc 2.1 until some
carefully planned time, since it will probably require bumping the major
version numbers of some (perhaps non-trivial) number of shared
libraries.
These sorts of things are important. Everyone in the Linux community
--- glibc developers, kernel developer, Linux distribution maintainers,
application developers --- needs to do their part; it's not just someone
else's problem.
- Ted
-
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/