lkml.org 
[lkml]   [2006]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Development tree, PLEASE?
    * Michael Loftis <mloftis@wgops.com> [2006-01-20 08:17:40 -0700]:

    > OK, I don't know abotu others, but I'm starting to get sick of this
    > unstable stable kernel. Either change the statements allover that were
    > made that even-numbered kernels were going to be stable or open 2.7.
    > Removing devfs has profound effects on userland. It's one thing to screw
    > with all of the embedded developers, nearly all kernel module developers,
    > etc, by changing internal APIs but this is completely out of hand.
    >
    > Normally I wouldn't care, and I'd just stay away from 'stable' until
    > someone finally figured out that a dev tree really is needed, but I can't
    > stay quiet anymore. 2.6.x is anything but stable right now. It might be
    > stable in the sense that most any development kernel is stable in that it
    > runs without crashing, but it's not at all stable in the sense that
    > everything is changing as if it were an odd numbered dev tree.
    >
    > Yes, I'm venting some frustrations here, but I can't be the only one. I
    > know now I'm going to be called a troll or a naysayer but whatever. The
    > fact is it needs saying. I shouldn't have to do major changes to
    > accomodate sysfs in a *STABLE* kernel when going between point revs. This
    > is just not how it's been done in the past.
    >
    > I can sympathize with the need to push code out to users faster, and to
    > simplify maintenance as LK is a huge project, but at the expense of how
    > many developers?

    For my daily work I use the -git kernels on my production machines. And I didn't
    have probs for a long time due to stuff being tested in -mm. -mm is mostly
    broken for me (psmouse, now reiserfs, ...) but I tend to say that 2.6 is
    rock-stable.

    When it comes to API stability people are encouraged to stay up-to-date when
    when developing stuff out of the kernel tree, ain't they? A more convenient way
    would be to create a new in-kernel-tree wrapper module that wraps some functions
    no longer available anymore and which are possible to be wrapped in the meaning
    of all needed data is provided to the 'old' method and can be easyily wrapped
    into the new function.

    It could a Kconfig option so that the 'wrapper module' is only activated on
    demand. Thus, having the option to port driver directly to the new API or just
    silenty use the 'wrapper module' to translate the call while being noisy at
    compile time.

    You're free to write the module... ;)

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

    \
     
     \ /
      Last update: 2006-01-20 17:03    [W:2.291 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site