[PATCH] xen/console: make console buffer size configurable

[PATCH] xen/console: make console buffer size configurable

[dmkhn]

Add new CONRING_SIZE Kconfig parameter to specify the boot console buffer size
in bytes. The value is rounded to the nearest power of 2 to match existing
conring_size= behavior.

The supported range is [16KiB..128MiB].

Bump default size to 32 KiB.

Link: https://gitlab.com/xen-project/xen/-/issues/185
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
Link to the original change:
- https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-15-c5d36b31d66c@ford.com/
---
 docs/misc/xen-command-line.pandoc |  5 ++++-
 xen/drivers/char/Kconfig          | 12 ++++++++++++
 xen/drivers/char/console.c        |  6 +++---
 3 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 9bbd00baef..563cdbdd49 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -425,10 +425,13 @@ The following are examples of correct specifications:
 ### conring_size
 > `= <size>`
 
-> Default: `conring_size=16k`
+> Default: `conring_size=32k`
 
 Specify the size of the console ring buffer.
 
+The console ring buffer size can be selected at build time via
+CONFIG_CONRING_SIZE.
+
 ### console
 > `= List of [ vga | com1[H,L] | com2[H,L] | pv | dbgp | ehci | xhci | none ]`
 
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index e6e12bb413..54a3a79da3 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -96,6 +96,18 @@ config SERIAL_TX_BUFSIZE
 
 	  Default value is 32768 (32KiB).
 
+config CONRING_SIZE
+	int "Console buffer size"
+	default 32768
+	range 16384 134217728
+	help
+	  Select the boot console buffer size (in bytes).
+	  Note, the value provided will be rounded down to the nearest power of 2.
+	  Run-time console buffer size is the same as the boot console size,
+	  unless overridden via 'conring_size=' boot parameter.
+
+	  Default value is 32768 (32KiB).
+
 config XHCI
 	bool "XHCI DbC UART driver"
 	depends on X86
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index ee5f720de4..73d24a7821 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -101,12 +101,12 @@ static int cf_check parse_console_timestamps(const char *s);
 custom_runtime_param("console_timestamps", parse_console_timestamps,
                      con_timestamp_mode_upd);
 
-/* conring_size: allows a large console ring than default (16kB). */
+/* conring_size: override build-time CONRING_SIZE setting. */
 static uint32_t __initdata opt_conring_size;
 size_param("conring_size", opt_conring_size);
 
-#define _CONRING_SIZE 16384
-#define CONRING_IDX_MASK(i) ((i)&(conring_size-1))
+#define _CONRING_SIZE       (1UL << (31 - __builtin_clz(CONFIG_CONRING_SIZE)))
+#define CONRING_IDX_MASK(i) ((i) & (conring_size - 1))
 static char __initdata _conring[_CONRING_SIZE];
 static char *__read_mostly conring = _conring;
 static uint32_t __read_mostly conring_size = _CONRING_SIZE;
-- 
2.34.1

Re: [PATCH] xen/console: make console buffer size configurable

[Stefano Stabellini]

On Wed, 12 Feb 2025, dmkhn@proton.me wrote:
> Add new CONRING_SIZE Kconfig parameter to specify the boot console buffer size
> in bytes. The value is rounded to the nearest power of 2 to match existing
> conring_size= behavior.
> 
> The supported range is [16KiB..128MiB].
> 
> Bump default size to 32 KiB.
> 
> Link: https://gitlab.com/xen-project/xen/-/issues/185
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
> Link to the original change:
> - https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-15-c5d36b31d66c@ford.com/
> ---
>  docs/misc/xen-command-line.pandoc |  5 ++++-
>  xen/drivers/char/Kconfig          | 12 ++++++++++++
>  xen/drivers/char/console.c        |  6 +++---
>  3 files changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
> index 9bbd00baef..563cdbdd49 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -425,10 +425,13 @@ The following are examples of correct specifications:
>  ### conring_size
>  > `= <size>`
>  
> -> Default: `conring_size=16k`
> +> Default: `conring_size=32k`
>  
>  Specify the size of the console ring buffer.
>  
> +The console ring buffer size can be selected at build time via
> +CONFIG_CONRING_SIZE.
> +
>  ### console
>  > `= List of [ vga | com1[H,L] | com2[H,L] | pv | dbgp | ehci | xhci | none ]`
>  
> diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
> index e6e12bb413..54a3a79da3 100644
> --- a/xen/drivers/char/Kconfig
> +++ b/xen/drivers/char/Kconfig
> @@ -96,6 +96,18 @@ config SERIAL_TX_BUFSIZE
>  
>  	  Default value is 32768 (32KiB).
>  
> +config CONRING_SIZE
> +	int "Console buffer size"
> +	default 32768
> +	range 16384 134217728
> +	help
> +	  Select the boot console buffer size (in bytes).
> +	  Note, the value provided will be rounded down to the nearest power of 2.
> +	  Run-time console buffer size is the same as the boot console size,
> +	  unless overridden via 'conring_size=' boot parameter.
> +
> +	  Default value is 32768 (32KiB).
> +
>  config XHCI
>  	bool "XHCI DbC UART driver"
>  	depends on X86
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index ee5f720de4..73d24a7821 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -101,12 +101,12 @@ static int cf_check parse_console_timestamps(const char *s);
>  custom_runtime_param("console_timestamps", parse_console_timestamps,
>                       con_timestamp_mode_upd);
>  
> -/* conring_size: allows a large console ring than default (16kB). */
> +/* conring_size: override build-time CONRING_SIZE setting. */
>  static uint32_t __initdata opt_conring_size;
>  size_param("conring_size", opt_conring_size);
>  
> -#define _CONRING_SIZE 16384
> -#define CONRING_IDX_MASK(i) ((i)&(conring_size-1))
> +#define _CONRING_SIZE       (1UL << (31 - __builtin_clz(CONFIG_CONRING_SIZE)))
> +#define CONRING_IDX_MASK(i) ((i) & (conring_size - 1))
>  static char __initdata _conring[_CONRING_SIZE];
>  static char *__read_mostly conring = _conring;
>  static uint32_t __read_mostly conring_size = _CONRING_SIZE;
> -- 
> 2.34.1
> 
> 

Re: [PATCH] xen/console: make console buffer size configurable

[Jan Beulich]

On 12.02.2025 23:31, dmkhn@proton.me wrote:
> --- a/xen/drivers/char/Kconfig
> +++ b/xen/drivers/char/Kconfig
> @@ -96,6 +96,18 @@ config SERIAL_TX_BUFSIZE
>  
>  	  Default value is 32768 (32KiB).
>  
> +config CONRING_SIZE
> +	int "Console buffer size"
> +	default 32768
> +	range 16384 134217728
> +	help
> +	  Select the boot console buffer size (in bytes).

Why in bytes when ...

> +	  Note, the value provided will be rounded down to the nearest power of 2.

... this rounding is done anyway? Why have people type in complicated numbers?
A granularity of 1k would already be an improvement; yet better would be if
this was a power-of-two value altogether.

Jan

Re: [PATCH] xen/console: make console buffer size configurable

[Denis Mukhin]

On Tuesday, February 18th, 2025 at 8:05 AM, Jan Beulich <jbeulich@suse.com> wrote:

>
>
> On 12.02.2025 23:31, dmkhn@proton.me wrote:
>
> > --- a/xen/drivers/char/Kconfig
> > +++ b/xen/drivers/char/Kconfig
> > @@ -96,6 +96,18 @@ config SERIAL_TX_BUFSIZE
> >
> > Default value is 32768 (32KiB).
> >
> > +config CONRING_SIZE
> > + int "Console buffer size"
> > + default 32768
> > + range 16384 134217728
> > + help
> > + Select the boot console buffer size (in bytes).
>
>
> Why in bytes when ...
>
> > + Note, the value provided will be rounded down to the nearest power of 2.
>
>
> ... this rounding is done anyway? Why have people type in complicated numbers?
> A granularity of 1k would already be an improvement; yet better would be if
> this was a power-of-two value altogether.

My understanding that the semantics of new CONFIG_CONRING_SIZE build-time setting
should be consistent with existing boot-time conring_size= behavior (string value
converted to number of bytes).

I can update both to round up to 1k boundary.

I also agree that having power of 2s for both (e.g. similar to Linux'es CONFIG_LOG_BUF_SHIFT)
will be the simplest (implementation) and non-ambigous.
I had it done earlier:
  https://lore.kernel.org/xen-devel/20241205-vuart-ns8250-v1-26-e9aa923127eb@ford.com/

Also, since there's a build-time configuration parameter along with the boot-time
configuration, perhaps it makes sense to retire boot-time setting in favor of
build-time setting?

>
> Jan

Re: [PATCH] xen/console: make console buffer size configurable

[Marek Marczykowski-Górecki]

[-- Attachment #1: Type: text/plain, Size: 456 bytes --]

On Fri, Feb 21, 2025 at 08:52:47PM +0000, Denis Mukhin wrote:
> Also, since there's a build-time configuration parameter along with the boot-time
> configuration, perhaps it makes sense to retire boot-time setting in favor of
> build-time setting?

IMO boot time setting is still useful to have, to not require rebuilding
just if you want bigger buffer in some specific case.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] xen/console: make console buffer size configurable

[Denis Mukhin]

On Friday, February 21st, 2025 at 2:13 PM, Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> wrote:

> 
> 
> On Fri, Feb 21, 2025 at 08:52:47PM +0000, Denis Mukhin wrote:
> 
> > Also, since there's a build-time configuration parameter along with the boot-time
> > configuration, perhaps it makes sense to retire boot-time setting in favor of
> > build-time setting?
> 
> 
> IMO boot time setting is still useful to have, to not require rebuilding
> just if you want bigger buffer in some specific case.

Ack.

> 
> --
> Best Regards,
> Marek Marczykowski-Górecki
> Invisible Things Lab

Re: [PATCH] xen/console: make console buffer size configurable

[Jan Beulich]

On 21.02.2025 21:52, Denis Mukhin wrote:
> On Tuesday, February 18th, 2025 at 8:05 AM, Jan Beulich <jbeulich@suse.com> wrote:
>> On 12.02.2025 23:31, dmkhn@proton.me wrote:
>>> --- a/xen/drivers/char/Kconfig
>>> +++ b/xen/drivers/char/Kconfig
>>> @@ -96,6 +96,18 @@ config SERIAL_TX_BUFSIZE
>>>
>>> Default value is 32768 (32KiB).
>>>
>>> +config CONRING_SIZE
>>> + int "Console buffer size"
>>> + default 32768
>>> + range 16384 134217728
>>> + help
>>> + Select the boot console buffer size (in bytes).
>>
>>
>> Why in bytes when ...
>>
>>> + Note, the value provided will be rounded down to the nearest power of 2.
>>
>>
>> ... this rounding is done anyway? Why have people type in complicated numbers?
>> A granularity of 1k would already be an improvement; yet better would be if
>> this was a power-of-two value altogether.
> 
> My understanding that the semantics of new CONFIG_CONRING_SIZE build-time setting
> should be consistent with existing boot-time conring_size= behavior (string value
> converted to number of bytes).
> 
> I can update both to round up to 1k boundary.
> 
> I also agree that having power of 2s for both (e.g. similar to Linux'es CONFIG_LOG_BUF_SHIFT)
> will be the simplest (implementation) and non-ambigous.
> I had it done earlier:
>   https://lore.kernel.org/xen-devel/20241205-vuart-ns8250-v1-26-e9aa923127eb@ford.com/

I'd prefer the power-of-2 approach, yet I could live with the Kb-based one as
was suggested by Roger.

> Also, since there's a build-time configuration parameter along with the boot-time
> configuration, perhaps it makes sense to retire boot-time setting in favor of
> build-time setting?

Why would that be? Build-time settings can only ever be defaults. We don't
know what people need in their configurations.

Jan

Re: [PATCH] xen/console: make console buffer size configurable

[Denis Mukhin]

On Monday, February 24th, 2025 at 2:44 AM, Jan Beulich <jbeulich@suse.com> wrote:

> 
> 
> On 21.02.2025 21:52, Denis Mukhin wrote:
> 
> > On Tuesday, February 18th, 2025 at 8:05 AM, Jan Beulich jbeulich@suse.com wrote:
> > 
> > > On 12.02.2025 23:31, dmkhn@proton.me wrote:
> > > 
> > > > --- a/xen/drivers/char/Kconfig
> > > > +++ b/xen/drivers/char/Kconfig
> > > > @@ -96,6 +96,18 @@ config SERIAL_TX_BUFSIZE
> > > > 
> > > > Default value is 32768 (32KiB).
> > > > 
> > > > +config CONRING_SIZE
> > > > + int "Console buffer size"
> > > > + default 32768
> > > > + range 16384 134217728
> > > > + help
> > > > + Select the boot console buffer size (in bytes).
> > > 
> > > Why in bytes when ...
> > > 
> > > > + Note, the value provided will be rounded down to the nearest power of 2.
> > > 
> > > ... this rounding is done anyway? Why have people type in complicated numbers?
> > > A granularity of 1k would already be an improvement; yet better would be if
> > > this was a power-of-two value altogether.
> > 
> > My understanding that the semantics of new CONFIG_CONRING_SIZE build-time setting
> > should be consistent with existing boot-time conring_size= behavior (string value
> > converted to number of bytes).
> > 
> > I can update both to round up to 1k boundary.
> > 
> > I also agree that having power of 2s for both (e.g. similar to Linux'es CONFIG_LOG_BUF_SHIFT)
> > will be the simplest (implementation) and non-ambigous.
> > I had it done earlier:
> > https://lore.kernel.org/xen-devel/20241205-vuart-ns8250-v1-26-e9aa923127eb@ford.com/
> 
> 
> I'd prefer the power-of-2 approach, yet I could live with the Kb-based one as
> was suggested by Roger.

Just to double check: I think it makes sense to switch both build-time and run-time
settings to use the same size calculation algorithm (e.g. Kb-based) to avoid
confusion during building hypervisor configuration.

Will that be OK to do such change?

> 
> > Also, since there's a build-time configuration parameter along with the boot-time
> > configuration, perhaps it makes sense to retire boot-time setting in favor of
> > build-time setting?
> 
> 
> Why would that be? Build-time settings can only ever be defaults. We don't
> know what people need in their configurations.

I was thinking about few reasons.
In embedded setup run-time settings are unlikely to change, it is mostly
built-time configuration.
On a server setup, bumping the size of console buffer morelikely means some
debugging, which to me means new xen binary can be re-generated and re-deployed.
Also, having dynamically configured options will add some extra burden for the
follow-on cert work.

I will keep both, just want to make sure that both settings are preferred.

> 
> Jan

Re: [PATCH] xen/console: make console buffer size configurable

[Jan Beulich]

On 25.02.2025 03:45, Denis Mukhin wrote:
> On Monday, February 24th, 2025 at 2:44 AM, Jan Beulich <jbeulich@suse.com> wrote:
> 
>>
>>
>> On 21.02.2025 21:52, Denis Mukhin wrote:
>>
>>> On Tuesday, February 18th, 2025 at 8:05 AM, Jan Beulich jbeulich@suse.com wrote:
>>>
>>>> On 12.02.2025 23:31, dmkhn@proton.me wrote:
>>>>
>>>>> --- a/xen/drivers/char/Kconfig
>>>>> +++ b/xen/drivers/char/Kconfig
>>>>> @@ -96,6 +96,18 @@ config SERIAL_TX_BUFSIZE
>>>>>
>>>>> Default value is 32768 (32KiB).
>>>>>
>>>>> +config CONRING_SIZE
>>>>> + int "Console buffer size"
>>>>> + default 32768
>>>>> + range 16384 134217728
>>>>> + help
>>>>> + Select the boot console buffer size (in bytes).
>>>>
>>>> Why in bytes when ...
>>>>
>>>>> + Note, the value provided will be rounded down to the nearest power of 2.
>>>>
>>>> ... this rounding is done anyway? Why have people type in complicated numbers?
>>>> A granularity of 1k would already be an improvement; yet better would be if
>>>> this was a power-of-two value altogether.
>>>
>>> My understanding that the semantics of new CONFIG_CONRING_SIZE build-time setting
>>> should be consistent with existing boot-time conring_size= behavior (string value
>>> converted to number of bytes).
>>>
>>> I can update both to round up to 1k boundary.
>>>
>>> I also agree that having power of 2s for both (e.g. similar to Linux'es CONFIG_LOG_BUF_SHIFT)
>>> will be the simplest (implementation) and non-ambigous.
>>> I had it done earlier:
>>> https://lore.kernel.org/xen-devel/20241205-vuart-ns8250-v1-26-e9aa923127eb@ford.com/
>>
>>
>> I'd prefer the power-of-2 approach, yet I could live with the Kb-based one as
>> was suggested by Roger.
> 
> Just to double check: I think it makes sense to switch both build-time and run-time
> settings to use the same size calculation algorithm (e.g. Kb-based) to avoid
> confusion during building hypervisor configuration.
> 
> Will that be OK to do such change?

No, you can't change existing command line options like this, at least not
without a very good reason. You'd break existing uses. Plus there is

size_param("conring_size", opt_conring_size);

already anyway, so the command line option can be used with Kb and other
granularities without any adjustments to the code.

>>> Also, since there's a build-time configuration parameter along with the boot-time
>>> configuration, perhaps it makes sense to retire boot-time setting in favor of
>>> build-time setting?
>>
>>
>> Why would that be? Build-time settings can only ever be defaults. We don't
>> know what people need in their configurations.
> 
> I was thinking about few reasons.
> In embedded setup run-time settings are unlikely to change, it is mostly
> built-time configuration.
> On a server setup, bumping the size of console buffer morelikely means some
> debugging, which to me means new xen binary can be re-generated and re-deployed.

That depends on who's doing the debugging and who's giving the instructions.
A developer telling a customer to increase the buffer size is certainly
easier when it simply means adding/changing a command line option, for
example.

Jan

Re: [PATCH] xen/console: make console buffer size configurable

[Denis Mukhin]

On Monday, February 24th, 2025 at 11:23 PM, Jan Beulich <jbeulich@suse.com> wrote:

> 
> 
> On 25.02.2025 03:45, Denis Mukhin wrote:
> 
> > On Monday, February 24th, 2025 at 2:44 AM, Jan Beulich jbeulich@suse.com wrote:
> > 
> > > On 21.02.2025 21:52, Denis Mukhin wrote:
> > > 
> > > > On Tuesday, February 18th, 2025 at 8:05 AM, Jan Beulich jbeulich@suse.com wrote:
> > > > 
> > > > > On 12.02.2025 23:31, dmkhn@proton.me wrote:
> > > > > 
> > > > > > --- a/xen/drivers/char/Kconfig
> > > > > > +++ b/xen/drivers/char/Kconfig
> > > > > > @@ -96,6 +96,18 @@ config SERIAL_TX_BUFSIZE
> > > > > > 
> > > > > > Default value is 32768 (32KiB).
> > > > > > 
> > > > > > +config CONRING_SIZE
> > > > > > + int "Console buffer size"
> > > > > > + default 32768
> > > > > > + range 16384 134217728
> > > > > > + help
> > > > > > + Select the boot console buffer size (in bytes).
> > > > > 
> > > > > Why in bytes when ...
> > > > > 
> > > > > > + Note, the value provided will be rounded down to the nearest power of 2.
> > > > > 
> > > > > ... this rounding is done anyway? Why have people type in complicated numbers?
> > > > > A granularity of 1k would already be an improvement; yet better would be if
> > > > > this was a power-of-two value altogether.
> > > > 
> > > > My understanding that the semantics of new CONFIG_CONRING_SIZE build-time setting
> > > > should be consistent with existing boot-time conring_size= behavior (string value
> > > > converted to number of bytes).
> > > > 
> > > > I can update both to round up to 1k boundary.
> > > > 
> > > > I also agree that having power of 2s for both (e.g. similar to Linux'es CONFIG_LOG_BUF_SHIFT)
> > > > will be the simplest (implementation) and non-ambigous.
> > > > I had it done earlier:
> > > > https://lore.kernel.org/xen-devel/20241205-vuart-ns8250-v1-26-e9aa923127eb@ford.com/
> > > 
> > > I'd prefer the power-of-2 approach, yet I could live with the Kb-based one as
> > > was suggested by Roger.
> > 
> > Just to double check: I think it makes sense to switch both build-time and run-time
> > settings to use the same size calculation algorithm (e.g. Kb-based) to avoid
> > confusion during building hypervisor configuration.
> > 
> > Will that be OK to do such change?
> 
> 
> No, you can't change existing command line options like this, at least not
> without a very good reason. You'd break existing uses. Plus there is
> 
> size_param("conring_size", opt_conring_size);
> 
> already anyway, so the command line option can be used with Kb and other
> granularities without any adjustments to the code.

OK, thanks.

> 
> > > > Also, since there's a build-time configuration parameter along with the boot-time
> > > > configuration, perhaps it makes sense to retire boot-time setting in favor of
> > > > build-time setting?
> > > 
> > > Why would that be? Build-time settings can only ever be defaults. We don't
> > > know what people need in their configurations.
> > 
> > I was thinking about few reasons.
> > In embedded setup run-time settings are unlikely to change, it is mostly
> > built-time configuration.
> > On a server setup, bumping the size of console buffer morelikely means some
> > debugging, which to me means new xen binary can be re-generated and re-deployed.
> 
> 
> That depends on who's doing the debugging and who's giving the instructions.
> A developer telling a customer to increase the buffer size is certainly
> easier when it simply means adding/changing a command line option, for
> example.

Ack.

> 
> Jan

Re: [PATCH] xen/console: make console buffer size configurable

[Denis Mukhin]

On Monday, February 24th, 2025 at 2:44 AM, Jan Beulich <jbeulich@suse.com> wrote:

> 
> 
> On 21.02.2025 21:52, Denis Mukhin wrote:
> 
> > On Tuesday, February 18th, 2025 at 8:05 AM, Jan Beulich jbeulich@suse.com wrote:
> > 
> > > On 12.02.2025 23:31, dmkhn@proton.me wrote:
> > > 
> > > > --- a/xen/drivers/char/Kconfig
> > > > +++ b/xen/drivers/char/Kconfig
> > > > @@ -96,6 +96,18 @@ config SERIAL_TX_BUFSIZE
> > > > 
> > > > Default value is 32768 (32KiB).
> > > > 
> > > > +config CONRING_SIZE
> > > > + int "Console buffer size"
> > > > + default 32768
> > > > + range 16384 134217728
> > > > + help
> > > > + Select the boot console buffer size (in bytes).
> > > 
> > > Why in bytes when ...
> > > 
> > > > + Note, the value provided will be rounded down to the nearest power of 2.
> > > 
> > > ... this rounding is done anyway? Why have people type in complicated numbers?
> > > A granularity of 1k would already be an improvement; yet better would be if
> > > this was a power-of-two value altogether.
> > 
> > My understanding that the semantics of new CONFIG_CONRING_SIZE build-time setting
> > should be consistent with existing boot-time conring_size= behavior (string value
> > converted to number of bytes).
> > 
> > I can update both to round up to 1k boundary.
> > 
> > I also agree that having power of 2s for both (e.g. similar to Linux'es CONFIG_LOG_BUF_SHIFT)
> > will be the simplest (implementation) and non-ambigous.
> > I had it done earlier:
> > https://lore.kernel.org/xen-devel/20241205-vuart-ns8250-v1-26-e9aa923127eb@ford.com/
> 
> 
> I'd prefer the power-of-2 approach, yet I could live with the Kb-based one as
> was suggested by Roger.

Reworked to power of 2.

> 
> > Also, since there's a build-time configuration parameter along with the boot-time
> > configuration, perhaps it makes sense to retire boot-time setting in favor of
> > build-time setting?
> 
> 
> Why would that be? Build-time settings can only ever be defaults. We don't
> know what people need in their configurations.
> 
> Jan