2004-01-07 17:12:25

by Joe Korty

Subject: reduce cpumask digit grouping from 8 to 4

As long as we are going to have a seperator in cpumask_t displays,
we might as well as group the digits into readable units.

Against 2.6.1-rc2.

--- base/lib/mask.c 2004-01-07 11:40:07.000000000 -0500
+++ new/lib/mask.c 2004-01-07 11:57:38.000000000 -0500
@@ -88,8 +88,8 @@
int __mask_snprintf_len(char *buf, unsigned int buflen,
const unsigned long *maskp, unsigned int maskbytes)
{
- u32 *wordp = (u32 *)maskp;
- int i = maskbytes/sizeof(u32) - 1;
+ u16 *wordp = (u16 *)maskp;
+ int i = maskbytes/sizeof(u16) - 1;
int len = 0;
char *sep = "";

2004-01-07 19:39:42

by Andrew Morton

Subject: Re: reduce cpumask digit grouping from 8 to 4

Joe Korty <[email protected]> wrote:
>
> As long as we are going to have a seperator in cpumask_t displays,
> we might as well as group the digits into readable units.
>
> Against 2.6.1-rc2.
>
> --- base/lib/mask.c 2004-01-07 11:40:07.000000000 -0500
> +++ new/lib/mask.c 2004-01-07 11:57:38.000000000 -0500
> @@ -88,8 +88,8 @@
> int __mask_snprintf_len(char *buf, unsigned int buflen,
> const unsigned long *maskp, unsigned int maskbytes)
> {
> - u32 *wordp = (u32 *)maskp;
> - int i = maskbytes/sizeof(u32) - 1;
> + u16 *wordp = (u16 *)maskp;
> + int i = maskbytes/sizeof(u16) - 1;
> int len = 0;
> char *sep = "";
>

What does the before-and-after output look like?

Thanks.

2004-01-08 02:15:45

by Paul Jackson

Subject: Re: reduce cpumask digit grouping from 8 to 4

Joe proposed changing mask displays from 8 to 4 chars:
- u32 *wordp = (u32 *)maskp;
- int i = maskbytes/sizeof(u32) - 1;
+ u16 *wordp = (u16 *)maskp;
+ int i = maskbytes/sizeof(u16) - 1;


Please don't apply this proposed patch as it stands.

It changes the output, without touching the input side (where the kernel
parses ascii masks from userland). The in and out formats should be the
same. See the other u32 appearances in this same file, mask.c, for the
other places that would need to be changed.

And I'd like to see a bit of a consensus for such a format change,
especially, in this case, from developers of systems with NR_CPUS in the
range of 17 to 32, who would go from a single ascii hex word to a
comma-separated double word with this change. My hunch is that they
would prefer not to make this proposed format change.

--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.650.933.1373