[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 recent Linux versions)
    Without quoting Monty, I was to detail how I've had similar problems
    over time: maintaining Linux-AFS. I also have some suggestions for
    ways to fix this problem later in this message.

    For those who do not know, AFS is the Andrew File System, a
    distributed file system developed at CMU, which currently MIT uses for
    all Unix file service. (As a side note, CMU's Coda filesystem is a
    spin-off from AFS from a decade ago -- today they look nothing alike,
    but the major design is similar).

    Back in 1994 I had the inenviable job of porting AFS to Linux. This
    entailed working with Linus and the Linux 1.1 kernel tree to get
    enough support into the core Linux kernel in order to load the AFS
    module. It was a lot of fun, and I think I had an impact on some
    parts of the Linux kernel, in particular parts of the VFS interface.

    The major problem with AFS is that it is copyrighted, commercial
    software. This means that the sources are only available under strict
    license agreement and cannot be distributed. MIT happens to be a
    source lincensee, so I was able to implement the port. However, the
    _ONLY_ way to distribute AFS is via binary objects. Fine, not a
    problem -- Linux has this great loadable kernel module system. No
    Problem, right? I just build a module, distribute it, and everyone
    can use it, right? WRONG.

    Oh, it was great in the early days. Remember the 1.2 stable release?
    Linux 1.2 was completely stable; the modules I built against 1.2.2
    still worked against 1.2.13. Ahh, the good old days.

    Next came the 1.3 kernels. I'm not going to complain about the Linux
    1.3 kernels -- I understand that they are development kernels. Things
    are moving, things are changing. No problem.

    Then Linux 2.0 was released. Unfortunately Linux 2.0 was not nearly
    as "stable" as Linux 1.2. During the tenure of the 2.0 kernels, there
    were many changes during the 'patch-level' releases that caused binary
    incompatibilities. I remember one change, I think it was somewhere
    around Linux 2.0.7, where the incompatible change was reordering the
    members of a structure! Think about it: binary incompatibilities due
    to REORDERING A STRUCTURE! Why was this done, you may ask? I did. I
    was told me it was a cache speed improvement. Gee, thanks. Break all
    binary compatibility for some potential small speed improvements? In
    a supposedly stable release? Why couldn't this wait?

    Put yourself in my place. What a nightmare! I had to Recompile,
    Test, Verify, and SHIP a new kernel module for practically EVERY
    KERNEL RELEASE during a supposedly 'stable' release cycle. Yea, so
    what? I shouldn't be shipping a binary module, right? That wasn't my
    choice. Sure, I could go with another vendor, right? No, there was
    no other vendor of AFS, so I was forced to use their product to access
    my files (as does everyone else in the world who uses AFS, and let me
    tell you there are a LOT of them!) So, what about writing my own free
    replacement? Umm, well, if you've never looked at AFS sources....
    Let's just say that at the time it wasn't practical (things have
    changed now, five years later) -- and besides, I was already tainted
    (oh right, that!)

    So, what about other others? How about choosing one kernel? Well,
    Slackware was using kernel X, RedHat was using kernel Y, Debian was
    using Kernel Z.... And, of course, all of them were mutually
    incompatible as far as my loadable kernel module. So, which one do I

    Don't even get me started down the road of libc, genksyms, or other
    user-space incompatibilities which caused other problems along the

    So, here I sit, frustrated with Linux and it's empty promise of a
    stable kernel release.

    At some level I'm still a strong fan of Linux, but I must admit that
    my attention is waning. I'm getting more and more frustrated that
    people are willing to make 'tweaks' with no regards for the
    consequences of their changes. I'm getting frustrated at kernel
    developers who don't understand the term 'stable release' (most seem
    to think it only means 'the kernel doesn't crash'). I'm getting
    frustrated with all the support questions I receive because someone
    built with patch A and configuration B which is incompatible with
    patch B and configuration A.

    Like it or not, Linux is now a "commercial" OS. What I mean is that
    Linux has been accepted by the commercial industry, and people in that
    industry demand stability. Companies are going to want to build their
    applications for Linux, but they will absolutely refuse to join the
    'build-of-the-week' club. They just want to build their product, test
    it, ship it, and support it -- and not have to repear the cycle for
    another 6 months.

    They demand stability. When Linux is in a stable release, it MUST
    remain truly stable. No longer can we change interfaces at a whim.
    No longer can we switch the order of structure members for 'speed
    improvements.' No longer can we be lax about our release engineering.
    During a stable release, the only changes that should go into the
    kernel are bug fixes (e.g., if you do foo the kernel crashes) or
    potentially security fixes (e.g., if you do foo, the user gains root

    Other changes, Speed enhancements, additional features, new support,
    all that should, no _must_, happen in next development cycle and wait
    for the next stable release, regardless of whose changes they are.

    But the next stable release is two years away?!? Well, maybe that
    should change. Maybe Linux should choose to operate with a real
    Software Development Process? Maybe features should only be
    integrated when they have been finished and tested? If a feature is
    only half complete, so be it -- it can wait (if it were more
    important, it would have been done ahead of other features, right?)
    Maybe we should try to get a stable release out every 6 months instead
    of every 24? Maybe we should have real code-freezes, where the only
    changes that go in affect the runability of the kernel (does it
    crash)? Maybe we should listen to our customers (yes, Linux has
    customers!) and let Linux go.

    The time has come for Linux to grow up. The time has come for Linux
    to leave the playground and join the office crowd. It is certainly a
    sad day for some, but I think every single person on this list wan't
    Linux to succeed. I know I want Linux to be a real thorn to the Evil
    Empire in the Pacific Northwest. But to do that Linux must grow up;
    Linux must act like a commercial OS; Linux must be STABLE.

    Anyways, I've taken enough bandwidth as it is. I just want you to sit
    back for a moment and think about where you want Linux to go? Do you
    want it to remain a hacker-only system, or do you want Linux to be the
    system-of-choice for everyone, competing with The Big Boys? Do you
    want more software support for Linux, or do you think your grandmother
    would be satisfied using 'ed' to compose email (ok, maybe emacs or vi
    ;)? Do you want more people demanding support for Linux? Do you want
    to see Linux accepted by more people in more industries?

    As I'm sure you are aware, people will be turned off by things that
    don't work. Just think about people's frustrations with M$ Windows!
    Currently, this model of changing kernel interfaces within supposedly
    stable releases DOESN'T WORK. It must change, or Linux will
    inevitably lose.

    I hope you can see the necessity of true stability.



    PS: If anyone is interested in Software Development Processes, I'd
    be happy to supply some input.
    Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
    Member, MIT Student Information Processing Board (SIPB)
    warlord@MIT.EDU PGP key available

    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.027 / U:40.788 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site