Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
What's the point of just converting specific subsystems like ext4?
The perils of pr_info()
Posted Mar 22, 2012 13:46 UTC (Thu) by dlang (✭ supporter ✭, #313)
Posted Mar 22, 2012 17:54 UTC (Thu) by liljencrantz (subscriber, #28458)
Posted Mar 22, 2012 18:02 UTC (Thu) by dlang (✭ supporter ✭, #313)
Posted Mar 23, 2012 11:47 UTC (Fri) by vonbrand (subscriber, #4458)
You've got a serious curly fingers problem there ;-)
Posted Mar 24, 2012 4:24 UTC (Sat) by jzbiciak (✭ supporter ✭, #5246)
I can kinda see the bind something like ext4 is in, since the change smacks a little of a "flag day" for "how ext4 prints messages from the kernel". Any bugfix or stability patch made to ext4 after the printk->pr_XXX change will be that much harder to backport those changes to a kernel that existed before that "flag day".
That said, once the pr_XXX functions have been in release kernels long enough that the oldest relevant 'stable' release has them (what's that, about a year? year and a half?), then it seems like you can incrementally start folding the pr_XXX changes in, file by file. Then a backport will convert some fraction of printk calls relatively painlessly, it seems. Either that, or you could execute a much less exciting 'flag day' patch on ext4 to convert printk to the newer forms, and make it a prereq for any further bugfixes/improvements. Because all the relevant back-port targets will have pr_XXX, at least it'll be mostly painless.
Right now, though, am I wrong in thinking that the printk->pr_XXX changes make it just that bit more difficult to migrate patches to older, pre-change kernels, as long as the patch overlaps one of these conversions?
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds