From: Paul J. <pj...@sg...> - 2004-06-15 18:08:45
|
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...@sg...> 1.650.933.1373 |