linux-kernel - Re: [PATCH 0/3] x86: add cpuset

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <47F399EE.4080704@sgi.com>
Date:	Wed, 02 Apr 2008 07:36:30 -0700
From:	Mike Travis <travis@....com>
To:	Paul Jackson <pj@....com>
CC:	mingo@...e.hu, tglx@...utronix.de, hpa@...or.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] x86: add cpuset_scnprintf function


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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/