Re: Development tree, PLEASE?

[Marc Koschewski <marc@osknowledge.org>]

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