Messages in this thread | | | Subject | Re: [PATCH] printk: support structured and multi-facility log messages | From | Joe Perches <> | Date | Thu, 05 Apr 2012 20:43:35 -0700 |
| |
On Thu, 2012-04-05 at 18:31 -0700, Linus Torvalds wrote: > On Thu, Apr 5, 2012 at 6:12 PM, Joe Perches <joe@perches.com> wrote: > > > > I still think this should be 3 patches not 1. > > I do agree that that would be lovely. That patch is really hard to > read, and it would be helpful if some of it was split up a bit. For > example, separating out the "move log buffer to be packetized" > (without actually doing the new things) from for the "introduce new > interfaces" would be quite nice. > > In fact, I think I could merge something that does the packetization > early, if it is fairly obvious that it doesn't do anything else. Just > making the dmesg ASCII timestamp be something that is a "read buffer" > time thing rather than "generate printk" time thing would be nice, and > I think the sequence numbers can be useful even with all the old > interfaces. > > So if somebody wants to help with things like that, and try to turn > this into a more gradual thing, I think we could merge at least some > initial parts of this patch even for 3.4. > > Anybody interested?
I think it'll be a lot more sensible to integrate this into a more granular printk subsystem so I've just done a move and split up of the printk bits.
kernel/printk.c -> kernel/printk/printk.c and a breakup of printk.c into 4 parts
kernel/printk/log_buf.[ch] kernel/printk/console.[ch] kernel/printk/kmsg.[ch] kernek/printk/printk.c
I think that's a lot more readable/extensible and will make adding a new printk_emit and devkmsg a bit simpler to understand as well.
Maybe it'd be useful to then add some compression to the log_buf message string bits.
I'll submit that move/separate tomorrow but not any compression after a few more compilation tests w/ & w/o the appropriate CONFIG_ options.
Kay would have to respin though.
| |