Re: [PATCH] delete devfs

From: Mike Snitzer (snitzer_at_gmail.com)
Date: 07/22/04

  • Next message: Mike Snitzer: "Re: [PATCH] delete devfs"
    Date:	Wed, 21 Jul 2004 19:33:31 -0600
    To: Brian Gerst <bgerst@didntduck.org>
    
    

    Here is a portion of the story; hopefully posting a snippet will not
    offend John Corbet. You guys really should just subscribe to LWN..
    the following is just a taste of the insight LWN has to offer:

    <snip>
    Linus talked about how happy just about everybody is with 2.6. It has
    been almost two years since the alleged 2.5 feature freeze, but there
    still is no great pressure to start a new development series. Linus
    asks: could things just go on the way they are for a while yet, until
    enough pressure forms to force the 2.7 fork?

    Bdale Garbee pointed out that, in the absence of a 2.7, many people
    will conclude that 2.6 has not yet stabilized sufficiently. There may
    be a need to do the fork just to convince people that 2.6 is ready.
    Alan Cox had a different idea: given that there is not a great deal of
    stuff to merge into 2.7, perhaps the developers could actually do a
    six-month release cycle for a change?

    Andrew pointed out that, during the 2.6 process, he and Linus have
    been merging patches at a rate of about 10MB/month. There is, he says,
    no reason to believe that things will not continue that way. The
    traditional stabilization mechanism, where almost no patches are
    accepted for long periods of time, does not strike him as a good idea.
    Instead, Andrew would like to see a 2.6 tree which continues to change
    and evolve, and let the distributors do the final stabilization work.
    In his vision of the future, the kernel.org kernel will be the most
    featureful and fastest kernel out there, but it will not necessarily
    be the most stable.

    The idea here is that restricting changes creates an incredible "patch
    pressure," which eventually leads to massive amounts of changes going
    into the kernel suddenly. At that point, things really do become
    unstable. It is better to keep the flow rate on patches higher; that
    keeps the developers happy and gets new code out to users quicker.
    Andrew really believes this: there are, seemingly, very few patches
    that he is not willing to accept into 2.6 - as long as they make sense
    and survive testing in -mm.

    These patches include API changes, incidentally. Stable internal
    kernel APIs have never been guaranteed, but the developers have
    usually tried to not make big changes during a stable kernel series.
    That looks to change now. Among other things, it was said that API
    changes should be merged before an eventual 2.7 fork, since that would
    make synchronization between the two trees easier. Your editor, who
    really would like to see Linux Device Drivers not go obsolete before
    it hits the shelves, finds this idea somewhat dismaying.

    What may happen is that Linus creates a 2.7 tree in the near future,
    but that tree will be restricted to truly experimental, destabilizing
    changes. This tree may have no future: if it doesn't work out, or
    can't be kept in sync with 2.6, it might simply be dropped. Or it
    could yet develop into 2.8, if that makes sense.

    On Wed, 21 Jul 2004 18:31:24 -0400, Brian Gerst <bgerst@didntduck.org> wrote:
    > Greg KH wrote:
    > > On Thu, Jul 22, 2004 at 12:02:38AM +0200, Adrian Bunk wrote:
    > >
    > >>>As for "right now"? Why not? I'm just embracing the new development
    > >>>model of the kernel :)
    > >>
    > >>Could anyone please explain this mysterious "new development model of
    > >>the kernel"?
    > >>
    > >>Is this some personal fight from you against Linus or someone else you
    > >>are trying to bring to linux-kernel, or WTF has happened???
    > >
    > >
    > > No fighting is going on here. I know lwn.net has already reported about
    > > this, see there for details. I don't have the time to write it up right
    > > now due to being at OLS.
    > >
    > > thanks,
    >
    > Ok, is there anywhere else that isn't subscriber-only that has the scoop?
    >
    > --
    > Brian Gerst
    >
    >
    > -
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    > Please read the FAQ at http://www.tux.org/lkml/
    >
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Mike Snitzer: "Re: [PATCH] delete devfs"

    Relevant Pages

    • Re: RFD: Kernel release numbering
      ... A different approach would be to not release a 'stable' kernel at all, ... applying patches that might be relevant to them. ... So I have been sending all my patches to Andrew to go in the -mm tree, ... But more recently I have discovered that quite a few key developers ...
      (Linux-Kernel)
    • Kernel Source Divergence, Security (was: booting gbde-encrypted filesystem)
      ... > There is a difference between loading the kernel from an encrypted volume ... I don't think it wise to have GBDE and GEOM subsystems which are rather ... before I post patches. ... implementation by core GEOM developers -- but even pjd isn't committing ...
      (freebsd-hackers)
    • Re: Documentation - how to apply patches for various trees
      ... > the various patches. ... > + Applying Patches To The Linux Kernel ... > +a patch to the kernel or, more specifically, what base kernel a patch for ... > +file and makes the changes to the source tree described in it. ...
      (Linux-Kernel)
    • [RFC] HOWTO do Linux kernel development - take 2
      ... Here's an updated version of the "HOTO do Linux kernel development" ... I'll send it in a patch for inclusion in the main tree soon. ... If anything in this document becomes out of date, please send in patches ...
      (Linux-Kernel)
    • Re: [PATCH]: How to be a kernel driver maintainer
      ... >> pushed to the primary kernel tree. ... 99% of the time, patches are going ... >> somewhere else before going into the main kernel. ... Each delta is meant to do a certain change to the driver, ...
      (Linux-Kernel)