lkml.org 
[lkml]   [1999]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Kernel interface changes (was Re: cdrecord problems on
    Date
    > >No the model of binary kernel modules doesn't work. Thats not my problem.
    > >Binary only compatibility is the cause of many of the problems in windows
    >
    > Unfortunately, I think it is a problem you have to take up and deal with.
    > Recompiling sources for entire server setups in a live production
    > environment because of a short->int conversion is nothing short of a
    > nightmare for those of us who have to do it. For huge security holes I can

    You aren't talking about recompiling sources for an entire server setup. You
    are talking about rebuilding the modules. Most people do that routinely when
    changing kernel anyway.

    Also nobody is talking about doing it gratuitously. If its everyone suffers
    or binary only modules they lose. I don't think any of us want to break binary
    only modules for fun.

    In 2.0.x I've no desire to change source compatibility unless I really have
    no choice. I've no desire to change binary compatibility unless there is
    no alternative. Torturing Derek Atkins is not my job description.

    > I think either (a) slower and better documented releases of the kernel/C
    > library or (b) a good binary compatibility layer that allows older kernel
    > modules to still work would help alleviate this. Examples could be either

    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.

    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.
    Glibc is a 32bit uid, large inode_t etc environment. When Linux kernel switches
    to 32bit uid the glibc apps wont even notice.

    So some of the work is being done and has been laid down very carefully.

    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.

    Alan


    -
    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/

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