[lkml]   [2004]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] Fix Device Power Management States

    On Wed, 2004-08-11 at 08:56, Patrick Mochel wrote:
    > On Wed, 11 Aug 2004, Nigel Cunningham wrote:
    > > I'm not intending to patch the current implementation into the new
    > > version; there are so many changes that it would make the process
    > > extremely painful (as evolution would have been if it were really true).
    > > Instead, I proposed, as Andrew requested to post a number of patches
    > > simply adding the new version along side the old. When you're satisfied
    > > that the new does everything the old does, I'm hoping we'll simply drop
    > > the old version.
    > Then there is something seriously wrong with your development process.

    No. It's just that the changes are so fundamental (how data is stored,
    how we prepare the image etc) that to talk about evolution is simply a
    misnomer. It's a redesign. The steps did occur one at a time, and there
    are basic similarities, but some of the steps were fundamental rewrites.

    > I'm sorry, but that's not how it works. There is no "flag day" for
    > switching from one feature to the next, whether they are drivers, APIs, or
    > suspend-to-disk implementations. And, I will definitely say, from
    > experience, that adding a second competing implementation of anything to
    > the kernel tree does little more than confuse users and developers.

    I agree with the last bit, and I don't want a second competing design.
    But there are flag days for some things, and multiple versions of some
    code are found in the kernel (suspend until recently, e100/eepro100
    driver...). This should be one of them.

    Once it is merged, the period of co-existence should be short anyway.
    Suspend 2 has had a ton of testing and is - dare I say it - virtually
    bugfree. There should be no reason to delay its including in Linus'

    > Making large changes to any piece of code is a long and tedious process,
    > and takes a lot of practice. But, it is imperative for the other people
    > working on it to be able to see improvements happen in steps, even if the
    > steps number in the 100s.
    > For example, see the way in which Al Viro works. One day, some driver will
    > be broken and unloved. Then Al will post a kajillion patches, each one
    > modifying 1-10 lines and making complete, obvious sense. When it's all
    > done, the result looks nothing like the original and the driver is
    > race-free and beautiful.
    > Rome was not built in a day, and neither is good kernel code.

    I'm not suggested it should be or that suspend2 was (it has been nearly
    two years since I posted my first patch). But I am suggesting that the
    process of working out bugs and thinking through design improvements has
    already been done and tested. I'm perfectly willing to submit 16 or 30
    patches, breaking up the changes into their main parts, but it is a
    waste of your time and mine for me to break it up further than that.

    That said, I'm sure there will also be suggestions that I can do some
    things better. I look forward to them. But I don't look forward to
    trying to break some of the irreducible changes down into artificially
    distinguished component parts.

    Nigel Cunningham
    Christian Reformed Church of Tuggeranong
    PO Box 1004, Tuggeranong, ACT 2901

    Many today claim to be tolerant. But true tolerance can cope with others
    being intolerant.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:05    [W:0.025 / U:18.048 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site