Messages in this thread | | | Date | Fri, 20 Jan 2006 16:59:19 +0100 | From | Marc Koschewski <> | Subject | Re: 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/
| |