[lkml]   [1997]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: buffer cache patches - anybody willing to summarize?

    On Sun, 3 Aug 1997, Jeff Wiegley wrote:

    > 2.0.31 now won't include as many bug fixes and updates as it might have
    > since Linus (appropriately) will only fix the fatal problems like the
    > buffer cache.

    Does this mean that we are looking at 2.2 (3.0?) possibly being not too
    far down the road? If there become too many features new 2.1 people who
    should be using the 2.0 set will start using 2.1 and we'll start getting
    flooded with "2.1.44 ate my HARD DRIVE!! DIE KERNEL SCUM!!".. <Sigh> Maby
    the 2.1.x should not be kept on the same servers where people get 2.0
    kernels from.. :) Or maby Linus should should think about declaring a
    semi-stable kernel once and a while.. So if you feel you must run 2.1.x
    you can run one that probably wont eat you hd..

    > the 2.1.X tree will fall behind a little now since you've forced Linus
    > to spend time on 2.0 (which other people like David were willing to
    > handle until the bitchy people ticked him off)

    Speaking of trees.. Anyone know if there are plans to intergrate the VMS
    (QNX?) style schduling.. I've yet to use it but I've used the evolutionary
    schduling, which has some of the same end results and It's nice..).. I'd
    like to see it as a /proc/ option.. (maby default on?)

    On the same line as the QNX schduler.. Has anyone looked into making
    fork() more restistant to bombing (like having fork priorities and
    demoting any process that forks like crazy when the process table is
    getting full)...

    And what happened to ZeroD? It seemed to accomplish the same kinds of
    improvements the pentium-memcpy patch did but it was a little more sane

    Or how about those wonderful non-exec-stack patches? They worked real
    well.. But no one bothered to read the docs and realize they didn't break
    signals, tramps, etc.. Is it still being maintained? Any concideration
    for becoming an compile time option?

    It would be nice to say that Linux is resistant to fork, while loop
    bombing without hard limits.. And as soon as buffer-overflow hacks become
    common on NT (There ARE SO MANY overflow problems with 95/NT I expect to
    see hacks soon), it would be nice to say that linux is one of the few OSes
    that can be made impervious to crummy programming!.. :)

    Is there some kinda agreement with the sound driver company that the
    kernel sound driver cant be as nice as their noncomercial version.. I'm
    not taking about menus and all.. Maby just the ability to have seperate
    modules for differnt cards and IRQ/IO as module options..

    And ext2 compression (I've used the patches on dummy computers.. Worked
    for me).. Various new mount options (i.e. noatime usecompression (to
    enable ext2compression) etc..), maby carring along some userspace mods to
    mount (i.e. autodetection for loopback device)..

    > so in the end 2.2 (3.0?) will farther down the road.

    Any word from Linus on if it will be 3.0? 3.0 versions make lotsa people
    feel more comfortible.. They dont realize the 3 version to fix bugs rule
    doesn't apply to free software..... It looks like the next version will
    def have enough new features to warrent a new major number.. Esp if maby
    during the 2.1.x seris we added the above patches, and maby 64-bit
    major/minor numbers.

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