On Thu, 2020-05-07 at 14:13 +0900, Tetsuo Handa wrote: > On 2020/05/07 10:02, Joe Perches wrote: > > > > printk_get_level / printk_skip_level and the various > > > > uses of %pV using printk_get_level > > > > > > > > > > Excuse me, but what do you mean? > > > > > > I wish printk() accepts "loglevel" argument detached from "fmt" argument > > > (e.g. > > > > I think that's a bad idea as it would expand > > _every_ use of printk with another argument > > and overall code size would increase for very > > little value. > > I'm not saying that we should add loglevel argument to all printk() callers. > I'm saying that we could add a variant of printk() which accepts loglevel > argument (say, e.g. printkl() and vprintkl()). > > I think that some of printk_get_level() users are using printk_get_level() > only > for detaching loglevel argument from fmt argument.
I believe wrote all of those. > I don't know how the lockless logbuf will replace printk_safe_flush_buffer(). > But I guess > it is possible to avoid printk_safe_flush_buffer() and printk_skip_level() as > demonstrated > by > https://lkml.kernel.org/r/5e192ca2-3b24-0b45-fc13-51feec43c...@i-love.sakura.ne.jp > . > > Then, printk_skip_headers() will be the only user of printk_skip_level(). I > don't know how > vkdb_printf() works, but vkdb_printf() is currently using printk_skip_level() > in order to > remove loglevel argument. We can avoid printk_skip_level() if loglevel > argument is detached > from fmt argument. a vprintk_emit variant would probably do. I proposed awhile back making functions for pr_<level> https://lore.kernel.org/lkml/1466739971-30399-1-git-send-email-...@perches.com/ Maybe it's time for that and something appropriate like it for your next use too.
