On Thu, 08 Jan 2026 14:36:21 +0100
"Danilo Krummrich" <[email protected]> wrote:
> (Cc: Greg, Rafael)
>
> On Thu Jan 8, 2026 at 1:55 PM CET, Gary Guo wrote:
> > In very early days (before RfL is upstreamed), I had a prototype print
> > macro that is designed like this:
> >
> > info!("foo"); // pr_info("foo\n");
> > info!(target: dev, "foo"); // dev_info(dev, "foo\n");
> > info!(target: dev, once, "foo"); // dev_info_once(dev, "foo\n");
> > info!(target: dev, ratelimited, "foo"); // dev_info_ratelimited(dev,
> > "foo\n");
> >
> > There's a trait that is implemented for anything that can be used as a
> > printing target.
> >
> > I still think this is superior than just having our macro mimicking the C
> > side (and as a result, having a lot of macros rather than just one for
> > each level).
>
> Why do you think this syntax is superior?
>
> One disadvantage for maintainers and reviewers would be that it is less
> convinient to grep for pr_*() vs dev_*(), which is something that people
> regularly get wrong. I.e. it regularly happens that people use pr_*() where
> they
> actually print in the context of a specific device.
>
One solution is perhaps to always ask people to specify a device so they
won't mix things up?
If they want to print without device then they can refer to `()` or
perhaps another marker type `info!(NoDevice, "...")`.
> > I think with Rust printing machinary, `pr_cont` is rarely useful, instead
> > of calling `pr_info` followed by multiple `pr_cont`, you can just have a
> > custom `Display` implementation and print it in one go. This is also free
> > from racing against another print and have your lines broken into two
> > parts.
>
> This I fully agree with.
>
> > I would be much in favour of vouching deleteing `pr_cont` entirely from
> > Rust codebase and always have newlines automatically added.
>
> I don't think it is a good idea to always add newlines. It might be fine if
> you
> only do C code or only do Rust code, but if you are switching back and forth,
> it
> is a horrible inconsistency for muscle memory.
>
> I'm pretty sure that this would turn into a generator for trivial fixup
> patches
> either removing or adding the trailing '\n'. :)
Well, we've seen that people will forget either way. :)
More seriously, printk actually strips out your newline. The new line at
the end of print gets turned into a flag on whether that log record is
continuable.
If we say "pr_cont" is not used in Rust, then it does not make sense to
leave any log entries continuable -- I would imagine in the future we
might even want to bypass all va-args machinary and just push the record
to the printk ringbuffer. Adding a newline just to have it stripped
doesn't sound ideal.
Best,
Gary
