Re: [PATCH v1] xen/console: remove __printk_ratelimit()

[dmkhn@proton.me]

On Sat, Jul 26, 2025 at 10:20:58AM +0100, Julien Grall wrote:

Hi Julien,

Thanks for your feedback!

I imagined that kind of a change may raise a question about importance of
doing it.

> Hi Denis,
> 
> On 25/07/2025 22:24, dmkhn@proton.me wrote:
> > From: Denis Mukhin <dmukhin@ford.com>
> >
> > __printk_ratelimit() is never used outside of the console driver.
> > Remove it from the lib.h and merge with the public printk_ratelimit().
> 
> Is this solving any sort of violation? Asking because even if the
> function is only used by one caller, I could see a benefit to be able to
> use different value for the ratelimit. So I leaning towards keep the
> code as-is.

The change is not solving any sort of violation, but simplifies a code path
slightly since fine-grain rate-limit controls are not exported/used anywhere
outside of the console driver. At this time, the purpose is a tiny cleanup.

TL;DR

I stepped over that code during addressing feedback for another change for
domain prefixes, where I'm experimenting with re-using printk-facilities from
guest_console_write(). This code showed up wrt rate-limiting for dom0's
messages. Just in case, experimental branch is here:
   https://gitlab.com/xen-project/people/dmukhin/xen/-/tree/console-fixes

I cannot anticipate not exposing rate-limiting timing controls in embedded
certifiable setup, perhaps there will be a legit use case in production
deployment.

But currently rate-limiting configuration happens at boot time only. The fact
that rate-limiting has not been touched since its introduction in 2006
    26cf03554a75 ("[XEN] Implement rate-limited logging.")
made me think that there's no intent to plumb any rate-limiting controls at
the run-time e.g. via keyhandler or a even hypercall.

Which resulted in this submission.

> 
> Cheers,
> 
> --
> Julien Grall
> 

Thanks,
Denis