Re: [PATCH] Introduce nodemask_t ADT [0/7]

[Paul Jackson]

> It's not quasi-const, it is const.

	Const cpumasks are not your Father's const references.
	======================================================

True, the current cpumask_const_t API makes essential use of the 'C'
const construct and semantics.

But it's not simply and entirely the usual const usage as seen in the
signature:

  char *strncpy(char *dest, const char *src, size_t n);

In this usual case, declaring something referenced by an argument
pointer as 'const' means the called function won't change the referenced
data.  For simple values such as the 'size_t n', it's not useful,
because these are simply pass by value, so changes by the called
function won't be visible to the caller anyway.  But when passing in
pointers, it has become useful in 'C' to indicate that the called
function won't mess with the pointed to data.

That's the usual use of the C keyword 'const', as I am sure you know
well.

You aren't simply marking parameters with the C 'const' keyword; you are
also labeling some functions and a cpumask typedef as const, embedding
the letters "_const" in the names.  Part of the cpumask_const_t
implementation uses the real C keyword 'const', but it's not simply the
classic usage shown above.

Each time I try to work with this, I have to scratch my head and think
a few minutes first.

Is the following a fair statement of this interface:

 1) Declaring a cpumask as type 'cpumask_const_t' means it might be passed
    to various cpumask '*_const()' methods either by value or by a const
    pointer, depending on the implementation (the size of the mask,
    presumably).

 2) The various cpumask '*_const()' methods expect to be passed such
    cpumask_const_t masks, and may actually pass by value or by const
    reference, at the discretion of the implementation, again.

So if I am not too confused, this non-C keyword embedded '_const' string
means something like "optionally pass masks by value or const pointer,
at the discretion of the implementation."

This is an abuse (or at the very least an extension) of our customary
use of the 'const' construct of the 'C' language, in my view; an abuse
with which users will never become comfortable.

You castigate yourself for not having converted more cpumask
manipulations to making full use of this quasi-const mechanism.

That way does not lay closure and sweet success.  You have provided a
weird API that will never become widely and comfortably used by others;
you will always find your available energies for putting it in use
yourself to be insufficient; you will be pushing this rock up the hill
throughout your years in purgatory (hopefully fewer years than I expect
to spend there ;).

I do not fault you for failing to put this interface to more wide
spread usage.  I do fault the interface for being a bit too weird
to obtain wide spread usage on its own, after it's original creation
and introduction.

Could you (Bill or any lurker) provide any specific examples of generic
code where it is important to pass by value on some architectures, but
by const reference on some other architectures?  Rather than distort the
API in general for such cases, I'd prefer to consider more narrowly
focused solutions that address such specific needs.  In general, I would
hope to be able to arrive at a cpumask (or even more generic mask as
multi-word bit mask) ADT that was always clear and explicit, using just
traditional 'C' idioms, as to whether arguments were pass by value or
reference, and which arguments were const reference or not-const.  If
some arch's (say sparc64) have arch-specific code that explicitly passes
a pointer to a cpumask, where similar code in some other arch passes by
value, that's fine, and an appropriate arch-specific optimization.  The
only challenges come in generic code for which arch's cannot agree on
any one form for passing a particular mask.  Examples anyone ... ?

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@xxxxxxx> 1.650.933.1373
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/