Re: [PATCH 0/3] x86: add cpuset_scnprintf function

Mike Travis
2008-04-02T14:36:42Z

Paul Jackson wrote:
...
> 1) I'm surprised to see this new routine called 'cpuset_scnprintf'
> (with the "cpuset" prefix), rather than a variant of a trio of
> names with prefixes of bitmap_, cpumask_, and nodemask_, like
> the other print routines in the bitmap family. This doesn't
> seem to be a cpuset function to me, but a bitmap (and derived
> types cpumask and nodemask) printing function.

How about "cpus_scnprintf" to avoid confusion with "cpusets"?

> 2) The idea of the patch, that being a kernel modal flag that if
> set, changes a few particular details of the kernel API for all,
> seems like something I'd rarely want to do, unless I was really
> short of other options. It leads to one app breaking another
> as a result of changing this mode, and to head butting between
> apps which cannot agree on how to set the mode. And it introduces
> the option of breaking an existing API, which is seldom a good
> option.

I could preface the cpulist_scnprintf output with '+' so a user app
could then:

if (buf[0] == '+')
bitmask_parselist(&buf[1], ...)
else
bitmask_parsehex(buf, ...)

or the perl equivalent which is probably more prevalent.

[I'll put this into the Documentation for compat_cpus_scnprintf...]

Does this sufficiently satisfy your concerns? It stays compatible with
the current method, but provides an avenue for future growth...?

> Kernel API's visible to kernel drivers or loadable modules have a
> higher barrier to change.

> Kernel API's visible to user space, such as this one, have a much
> higher barrier to incompatible change.

But where is the API spec for /proc outputs? I'd like to see how others
have managed to change it in the past, and what are the rules for doing so.

> I hesitate to NAQ patches because I strike out more often than someone
> like Al Viro. But I'm getting tempted on this one.
>
> Perhaps you could write yourself a user utility that scanned its input
> for masks in legacy format, converted them to list format, and passed
> all else unscathed?

Or write a utility to convert the more compact readable format into the
incomprehensible one and output that ... ? ;-)

Thanks,
Mike