On Wed, 2012-07-11 at 17:14 +0200, Kay Sievers wrote: > On Wed, Jul 11, 2012 at 5:01 PM, Joe Perches <[email protected]> wrote: [] > There are _many_ cases the console lock is held, and we don't print > stuff immediately out to the console, and we never ensured that in the > past. There was never a guarantee that stuff ended up on the console, > kmsg was always and needs to be a store+forward model.
I'm less concerned with kmsg than you. I think it's more a nicety than anything. > > It would require all sites with continuation lines > > be modified. Because it requires in-situ code > > modifications, I'd prefer a cookie based approach. > > Well, it would be mostly for the dev_printk() stuff, which should > ideally never be merged with stuff that could go wrong. Perhaps that's ideal, but not practical. printk continuations are more prevalent. > > I think it's more flexible, allows the cookie to be > > passed into extending functions and doesn't demand > > (much) extra stack. > > > > Something like: > > https://lkml.org/lkml/2012/4/3/231 > > https://lkml.org/lkml/2011/11/14/349 > > Hmm, how do we manage memory allocations here? We can get around that > somehow? It's something the common printk() must really avoid. Well, I think the malloc costs are pretty low and could devolve pretty easily when OOM. cookie=NULL, directly emit. Anyway, interesting idea, keep at it, see what comes out of it. cheers, Joe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
