On Mon, Jan 28, 2008 at 05:59:27PM +0000, Mindaugas R. wrote: > yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi) wrote: > > > Sorry for late reply, let's figure out this. My points was: > > > - Since MAXCPUS can only be increased, ABI would not be broken; > > > > MAXCPUS can only be increased? why? > > In time we would like to support more processors, not vice-versa :) > I guess you do not want to depend on such assumption? > > > anyway it depends on what do you mean by "ABI would not be broken". > > old schedctl binaries might not crash. however they can't handle > > the increased MAXCPUS properly. > > <...> > > True, this needs to be fixed... > > > > - Why silent truncation is wrong in this case? > > > > each truncated bits can be either 0 or 1. > > how can you know which was intended? > > In truncated part would be CPUs whose numbers are >= MAXCPUS. System does not > support them, so it does not matter. Your concern is error instead silence? No, the problem is how does a program we compile today correctly cope with a world where the size is larger? Or how does a library compiled today cope with a kernel and application that were built for a larger MAXCPUS. From what little I've been able to glean, you're repeating the mistake made with file sets in select(). Don't. > > > Are you suggesting CPUSET_SIZE to not depend on MAXCPUS? > > > > i'm suggesting to make it dynamic at least for userland programs. I fully agree. > > - syscalls should not truncate bitmaps silently. they should return > > appropriate errors. > > > > - userland should not assume the size of cpuset_t. > > there should be a way for userland to query the bitmap size > > for "get" syscalls. (probably like getsockopt) > Take care, Bill
Attachment:
pgpYSStCd4USM.pgp
Description: PGP signature