Weekly Edition
Return to the Kernel page
| |||||||||||||
MODULE_PARM deprecated
It's hard to turn down an opportunity to give Rusty Russell some grief, so
let's take a moment to review a comment he
posted on LWN in 2003:
Regarding module_param(): MODULE_PARM() will certainly stay
throughout the 2.6 series, so no need to change existing code just
yet.
Those who held off on changing their out-of-tree modules may want to do so now. Rusty has sent out a patch marking MODULE_PARM() obsolete in preparation for its removal from the kernel. A set of companion patches deals with many of the remaining MODULE_PARM() uses in the mainline tree. MODULE_PARM() declares parameters for loadable modules; these parameters can be changed when the module is loaded to affect its operation. One of the many changes that came with the new module loader in the 2.5 series was a new mechanism (module_param()) for declaring module parameters. The new scheme has a number of advantages over the old one: it is type safe, it allows module parameters to be represented (and changed) in sysfs, and it provides a flexible mechanism for new types of parameters. But, since the older way continued to work, many modules were never updated. Under the old development model, things probably would have gone as Rusty suggested: MODULE_PARM() would have remained through the 2.6 series in order to avoid breaking things. The new development model lacks the same sort of obvious demarcation point where compatibility can be broken, so those changes end up going into the regular patch stream. This is especially true of internal API changes, where there never has been a guarantee of any sort of continuity, even in an old-style stable series. So some of these changes are coming more quickly than some developers might have expected. With regard to MODULE_PARM, The current patches in circulation suggest that the time to update to module_param() is running out. Consider yourself warned. (Log in to post comments)
kernel development model?? Posted Oct 21, 2004 12:59 UTC (Thu) by tjasper (subscriber, #4310) [Link] This also relates to the other articles as part of the Linux kernel page. It seems to me that the kernel development model is morphing into an Andrew development/unstable kernel and a Linus stable kernel.
I guess, given the complexity of the kernel these days, that breaking off into a development series and then bringing it back to a stable series is getting to be harder and harder.
With a larger and more diverse code base is it perhaps, with small sections of development are going into Andrew's tree and stabilising and then being merged into the stable series, that a newer kernel development model is being forged now? This gets more up-to-date features out to users faster than the old cycle. For example, I'll bet that there was more code went into the 2.6.8 to 2.6.9 than went into the entire 1.1 or 1.3 trees? Yet this only waranted a dot.dot release now.
Is it time to do some conceptual blockbusting on the old development model, and not to expect a 2.7 series. Rather should we expect more and more development to go on in and upstream of the -mm trees, subsequently merged into mainline?
What then of version numbers? Should we consider the -mm to be the equivalent of a 2.7 series? Then 2.6.10 would be the equivalent of the 2.8 or 3.0? Perhaps, with the current model, a slight expansion of what actually gets into the -mm tree in terms of more radical development (such as Ingo's RT patches) get us back into the development vs stable series of old but in much more manageable sizes and keeps patch pressure down on the stable series, as it moves into each dot.dot release more quickly.
It seems/feels to me that 2.6 has evolved in small steps into something more like 2.8 without the big step change. Distributions seem to have an easier time of shipping dot.dot releases more regularly, and being much more up-to-date while they do it. It also gets many more users USING the latest releases which can only help code development.....
Trevor Jasper
kernel development model?? Posted Oct 21, 2004 19:34 UTC (Thu) by pivot (guest, #588) [Link] I think the reals reason is that they are slowing down the release number cycle so that it can become less or equal to PI. With each successive release, the kernel developers can then claim to have calculated another digit of PI.
kernel development model?? Posted Oct 23, 2004 1:09 UTC (Sat) by khim (subscriber, #9252) [Link] Since this joke is already used by TeX (Pi) and METAFONT (e) we should probably invent something new - there are enough interesting constants in the world...
kernel development model?? Posted Oct 27, 2004 16:01 UTC (Wed) by flewellyn (subscriber, #5047) [Link] Actually, the kernel version numbers are closest to e, so that would be the one to shoot for, perhaps.
kernel development model?? Posted Oct 21, 2004 21:26 UTC (Thu) by larryr (guest, #4030) [Link] It seems to me that the kernel development model is morphing into an Andrew development/unstable kernel and a Linus stable kernel.[...] should we expect more and more development to go on in and upstream of the -mm trees, subsequently merged into mainline? Larry
|
|||||||||||||