On Thu, Jan 8, 2026 at 2:36 PM 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.
>
> > 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'. :)
What about triggering a build failure if you forget the newline?
For cases where the \n is intentionally omitted for use with pr_cont!,
we can add separate syntax for making this explicit:
pr_info!("hello! thi", cont);
pr_cont!("s tring is split\n");
This way, you can't forget the newline, but you can still omit it if
you really want to use pr_cont.
Alice
