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

The perils of pr_info()

The perils of pr_info()

Posted Mar 24, 2012 4:24 UTC (Sat) by jzbiciak (subscriber, #5246)
In reply to: The perils of pr_info() by dlang
Parent article: The perils of pr_info()

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?


(Log in to post comments)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds