[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v1] xen/console: remove __printk_ratelimit()
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@xxxxxxxxx wrote: > > From: Denis Mukhin <dmukhin@xxxxxxxx> > > > > __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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |