User: Password:
|
|
Subscribe / Log in / New account

The perils of pr_info()

The perils of pr_info()

Posted Mar 22, 2012 12:32 UTC (Thu) by slashdot (guest, #22014)
Parent article: The perils of pr_info()

If it is decided that this is worthwhile, just convert the whole tree with a script and deprecate printk.

What's the point of just converting specific subsystems like ext4?


(Log in to post comments)

The perils of pr_info()

Posted Mar 22, 2012 13:46 UTC (Thu) by dlang (subscriber, #313) [Link]

Jon is going though the entire tree and making the changes, but the changes then get sent to the appropriate maintainer to be accepted. When he got around to the ext* tree, Ted gave an emphatic NAK to the pf_info() patches, while accepting and expressing appreciation for some of the other patches Jon provided.

The perils of pr_info()

Posted Mar 22, 2012 17:54 UTC (Thu) by liljencrantz (guest, #28458) [Link]

Jon == Joe in this case, right? (Honest question, not trying to be a wise ass)

The perils of pr_info()

Posted Mar 22, 2012 18:02 UTC (Thu) by dlang (subscriber, #313) [Link]

oops, yes. I was thinking Jow, but my fingers typed Jon :-(

The perils of pr_info()

Posted Mar 23, 2012 11:47 UTC (Fri) by vonbrand (guest, #4458) [Link]

You've got a serious curly fingers problem there ;-)

The perils of pr_info()

Posted Mar 24, 2012 4:24 UTC (Sat) by jzbiciak (subscriber, #5246) [Link]

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 © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds