(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.
> 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'. :)
- Danilo
