Re: NUMA API observations

[Paul Jackson]

Andi wrote:
> But it doesn't really help because
> applications have to work with older kernels.

It doesn't help right away.  But one can eventually phase out cruft.
Provide the new, deprecate the old, then perhaps in 2.7/2.8 kernels,
discontinue the old.

Such renewal work is valuable to the long term health of Linux.

I can't do it - I wouldn't want Andrew dreading my submissions anymore
than he already does, and William's questions as to just how I was
explaining to my employer the value of my labors would be increasingly
unanswerable. <grin>

> cpumask_t is more an kernel internal implementation detail
> and should not really be exposed to user space, so 
> it's better not to do the sysctl neither.

Bingo.

When you find yourself in a hole, stop digging.

I'd go a step further - even as an internal kernel detail, it was poorly
chosen, as evidenced by the amount of commentary it takes the big-endian
64 bit machines, in the files include/asm-ppc64/bitops.h and
include/asm-s390/bitops.h, to explain the bitmap data type.

Perhaps a byte array, rather than an unsigned long array, would be
better.

And the brain damage is also on the other side of the kernel-user
boundary.  Don't get me started on the botch that glibc made of this.

This is a nice case study in the propagation properties of suboptimal
design choices, and in the unintended consequences flowing from the
choices of basic data structures.

-- 
                          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/