On Mon, Jan 27, 2014 at 4:44 PM, Joe Perches <joe@xxxxxxxxxxx> wrote:
>
> There are very few uses overall of KERN_DEFAULT.
>
> I think KERN_DEFAULT should be removed actually.
> All the uses might be better with a specific level.
It's a long time ago, but I think one of the reasons for KERN_DEFAULT
was some of the precursor discussion to a different interface, where
people wanted to make the prefix a separate argument in order to
*force* it to be used. And that meant that you needed a separate value
for the default case, since you couldn't just skip it.
And that obviously never happened, and yes, KERN_DEFAULT is useless. I
agree that it could be removed, I'd just like the "no explicit level"
to behave like KERN_DEFAULT does..
>> Of course if people *really* want things on the same line, they usually end
>> up using sprintf() to save the individual pieces to some buffer and the dump
>> that out using one printk() call
>
> No, actually, they don't.
>
> There's probably much more code that uses KERN_CONT
> or no KERN_ level where it's intended that the printks
> be merged than uses of intermediate buffers.
>
> There are many uses of %pV that effectively serve as a
> mechanism to avoid using multiple printks though.
KERN_CONT is kind of hacky, but the thing is, it's very convenient.
And it's often used when it's important that things be reasonably
dense (in order to not make useless small details end up as lots of
useless separate lines), but for things that aren't really
*important*.
Sometimes people could generate single strings, but KERN_CONT is all
about convenience for those print-outs. And generating a bigger string
and then printing that all out in one go is often non-productive, when
you very much want to get incremental output (some of the really
traditional cases are for things like testing where you print the test
name and then "ok" afterwards, where you need to know that you're
testing even if the ok never happens - or _especially_ if the ok never
happens).
It's not a "good" interface, no. But it's a very simple and convenient
one for simple lists of supported features etc, and it actually does
have some cases where it would be actively *wrong* to try to do it the
"right" way with fancy preformatting.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
