lkml.org 
[lkml]   [2004]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Fix argument checking in sched_setaffinity
Linus wrote:
> I hate the "byte at a time" interface.
>
> That said, I think the "long at a time" interface we have now for bitmaps
> ends up being a compatibility problem, where the compat layer has to worry
> about big-endian 32-bit "long" lookign different from big-endian 64-bit
> "long".

My first preference would be to get all the binary bitmap interfaces
(affinity, mbind and mempolicy) "right":

I think that means an array of 'u32'. This parallels what I did for
the ascii format, where there was less need to remain compatible
(except that ascii is naturally big-endian, while the u32 array has
the low order word first):

$ cat /sys/devices/system/node/node0/cpumap
00000000,00000000,00000000,000000ff

No doubt Andi will veto this for mbind/mempolicy, because it breaks
libnuma's he has in the field - a reasonable concern. We'd probably
have to burn another couple of system calls, introducing the new API
while keeping the old one around, as is, for a year or three.

And this (array of u32) is different from the kernel bitmap, due to
the reversed u32 halves of each u64 on big endian 64 arches. If I
were God, the kernel bitmap would also be an array of u32's, not ulongs.
Still ... might as well start somewhere, and get the kernel/user API
"right", even if the kernel internals have an irreparable twist.

I agree with Andi that there should be an explicit way to get the
correct size - the loops cause too many user level code bugs, and
trying to accomodate user code that doesn't know the exact size is
causing our kernel code too much grief.

Possible ways to publish cpumask/nodemask sizes include:

1) # an ascii field in some proc file:

$ grep sizeof /proc/sys/kernel

2) sysctl

3) overload sched_getaffinity (for sizeof cpumask) and get_mempolicy
(for sizeof nodemask) to return the sizes if passed zero lengths
or NULL mask pointers or some other currently useless input.

My second preference would be what we had a week ago. Minor tweaks
(especially ones that relax the preconditions) to busted API's do more
harm than good. Leave 'em be, or get 'em "right". Quit putting
lipstick on a pig.

I was surprised that Andi came up with yet another tweak to this API
(his suggested patch to allow either 0x00 or 0xff fill). Surely Andi
doesn't need this for _his_ code, since he's competent to code to the
current API. So I guess he's trying to make life easier for others.
Eh ... doesn't seem worth it.

Leave it be, I say. Leave it be. Or get it right.

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

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.063 / U:0.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site