Re: [PATCH v6 02/11] printk: Use struct console for suppression and extended console state

[Chris Down <chris@chrisdown.name>]

John Ogness writes:
>On 2024-10-28, Chris Down <chris@chrisdown.name> wrote:
>> In preparation for supporting per-console loglevels, modify
>> printk_get_next_message() to accept the console itself instead of
>> individual arguments that mimic its fields.
>
>Sorry, this is not allowed. printk_get_next_message() was created
>specifically to locklessly retrieve and format arbitrary records. It
>must never be tied to a console because it has nothing to do with
>consoles (as can bee seen with the devkmsg_read() hack you added in the
>function).
>
>I recommend adding an extra argument specifying the level.
>
>The extra argument would be redundant if may_suppress=false. So perhaps
>as an alternative change "bool may_suppress" to "u32 supress_level". The
>loglevels are only 3 bits. So you could easily define a special value
>NO_SUPPRESS to represent the may_suppress=false case.
>
>#define NO_SUPPRESS BIT(31)
>
>bool printk_get_next_message(struct printk_message *pmsg, u64 seq,
>                             bool is_extended, u32 suppress_level);
>
>Then in devkmsg_read():
>
>printk_get_next_message(&pmsg, atomic64_read(&user->seq), true, NO_SUPRRESS)

Petr, what do you think about this? I remember when we discussed this before we 
talked about either determining state via `struct console` (which seems to turn 
out not to be feasible) or passing another argument.

Do you prefer to have another argument or do the bit dance?

Personally I prefer the simpler solution with more arguments instead of bit 
stuffing if we have to go this way, but I'm up for whichever sounds good to 
you.