From: Manfred S. <ma...@co...> - 2004-06-15 05:00:09
|
> > >> I will probably make it loop and double the buffer until EINVAL >> ends or it passes a page and add a nasty comment. > >I agree that a loop is needed. And yes someone didn't do a very >good job of designing this interface. > > > What about fixing the interface instead? For example if user_mask_ptr NULL, then sys_sched_{get,set}affinity return the bitmap size. -- Manfred |
From: Paul J. <pj...@sg...> - 2004-06-15 06:09:23
|
> What about fixing the interface instead? Yeah - if someone has the stomach, and time for such, it might be well received. Though this brain damage, and the further glibc brain damage down stream, will take a while to dissipate. Manfred - the copy of your email addressed back to me, "pj...@sg..." was instead addressed to: "pj () sgi ! com"@dbl.q-ag.de Needless to say, I never saw that copy. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj...@sg...> 1.650.933.1373 |
From: Andi K. <ak...@mu...> - 2004-06-15 11:03:27
|
On Tue, Jun 15, 2004 at 06:59:57AM +0200, Manfred Spraul wrote: > > > > > >>I will probably make it loop and double the buffer until EINVAL > >>ends or it passes a page and add a nasty comment. > > > >I agree that a loop is needed. And yes someone didn't do a very > >good job of designing this interface. > > > > > > > What about fixing the interface instead? For example if user_mask_ptr > NULL, then sys_sched_{get,set}affinity return the bitmap size. Or maybe just a sysctl. But it doesn't really help because applications have to work with older kernels. I think 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. However the clear bugs in the kernel API that should be fixed: - It should EINVAL for bits set above cpumask_t - It should not EINVAL as long as the passed in mask covers all online CPUs. -Andi |
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 |
From: Manfred S. <ma...@co...> - 2004-06-15 17:37:35
|
Andi Kleen wrote: >Or maybe just a sysctl. But it doesn't really help because >applications have to work with older kernels. > What's the largest number of cpus that are supported right now? 256? First call sysctl or whatever. If it fails, then glibc can assume 256. If someone installs an old kernel on a new computer then it's his own fault. The API is broken, we should fix it now - it will only get more painful in the future. -- Manfred |
From: Paul J. <pj...@sg...> - 2004-06-15 18:21:40
|
Manfred wrote: > What's the largest number of cpus that are supported right now? 256? Kernels for SGI's SN2 boxes are usually compiled with NR_CPUS == 512. A quick grep of the default config files shows that is the largest. > First call sysctl or whatever. If it fails, then glibc can assume 256. Yes, one _could_ write code such as that. Spend a little time looking at what glibc has done so far with these API's. You will then doubt that the code you recommend would actually happen consistently. Be forewarned - if you are on anti-depressant medications, make sure your prescription is filled first. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj...@sg...> 1.650.933.1373 |