Deprecated kernel functions [LWN.net]

One small patch that slipped into 2.5.54 is the addition of a new __deprecated function attribute. With a suitably modern compiler (gcc 3.1 or newer), calls to a function marked as being deprecated will generate compile-time warnings. The hope is that the warnings will inspire people to remove calls to the deprecated functions, making it easier to remove them altogether.

So far, this attribute has been used sparingly; the only functions which have been marked are check_region() (which has long been obsoleted by the race-free version of request_region() which returns a success value), and the old module use count macros (MOD_INC_USE_COUNT and MOD_DEC_USE_COUNT). Patches have been put forward to mark other functions, but there has been resistance to doing so, for a couple of reasons.

One reason, as expressed by Linus, is that the functions that have deprecated so far already generate far too many warnings. A quick grep turns up over 1000 check_region() calls in the 2.5 kernel. Adding more warnings to the mix is not going to help get things fixed, and may well just mask other warnings about real problems.

The other objection that has been raised is that trying to clean up use of deprecated functions at this stage distracts attention from the most important task: stabilizing the 2.5 kernel for release. The current code works, for the most part, even if it's using deprecated functions. It's hard to imagine cleaning up 1000 check_region() calls without breaking something, somewhere.

The end result is that, probably, not too many other kernel functions will be marked as deprecated in this development cycle. Some functions that had been expected to disappear (e.g. sleep_on()) will persist into 2.7 - they are still extensively used in some places. Cleaning up old stuff is never easy; it is simpler to put code into the kernel than to take it out.

(Log in to post comments)

Deprecated kernel functions

Posted Jan 9, 2003 9:51 UTC (Thu) by zmi (subscriber, #4829) [Link]

Maybe my english is not good enough, but didn't you mean that
check_region() is the old function and request_region() is the new one?
Then the 1000 request_region() calls would be OK.

Anyway, I think everybody gets the point that removing functions is not
an easy task ;-)

Thanks for your great service, I hope you find a lot more paying readers!

Michael Zieger,
Vienna, Austria, Europe

Two-stage feature freeze

Posted Jan 10, 2003 12:08 UTC (Fri) by perlid (guest, #6533) [Link]

Why not do as the gcc developers? They are using three stages to develop gcc: In first they are adding major features or doing major restructurings, in the second they do minor changes, and in the third they only fix bugs. After that they branch off a release branch, which is released after two additional months of fixing bugs and regressions. See http://gcc.gnu.org/develop.html for more info.

In gcc, all stages are (supposed to be) 2 months long, and this is probably not the best for the kernel development. But nevertheless it is maybe not a bad idea to have a stage where minor additions and, perhaps, cleanups of already merged features and performance fixes are allowed?

That is, splitting the feature freeze into a first, "soft" freeze, and after, say 3 monthts, use the "hard" feature freeze.

During that "soft" freeze, cleanups such as this would be allowed, thus making the kernel more stable when it is released.

Two-stage feature freeze

Posted Jan 13, 2003 5:09 UTC (Mon) by jzbiciak (✭ supporter ✭, #5246) [Link]

I thought that's approximately what we have with Linux today. (At least, theoretically.) The first stage, where major subsystems are torn up and redone, is for the "early odd-subversion kernels" (eg. 2.5.0 through, say, 2.5.40-ish). The second stage, where major features are frozen but a fair bit of shaking out still occurs, is for the "late odd-subversion kernels". That is the stage we're in now. The bugfix only stage comes with the even-subversion "stable" kernels (eg. 2.6.x). The biggest difference with Linux is that the stages take place over a much longer period of time than with the recent GCC regime.

As for the __deprecated tag: I agree now is not the time to be slapping that keyword on deprecated functions. That should've been done at the point where the interface becomes deprecated, which theoretically should've been early in 2.5.x. Patches which add __deprecated to functions are useful, and should be the first to be applied in 2.7.x.

--Joe