[lkml]   [1999]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Kernel interface changes (was Re: cdrecord problems on
       From: (Alan Cox)
    Date: Thu, 4 Feb 1999 01:56:30 +0000 (GMT)

    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

    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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:50    [W:0.022 / U:14.660 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site