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

[Mike Travis <travis@sgi.com>]

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