[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src
In article <20080130023737.GD7366%netbsd.org@localhost>,
Bill Stouder-Studenmund <wrstuden%netbsd.org@localhost> wrote:
>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)
Bill said it; let's not re-invent select. There is the poll solution :-)
Main Index |
Thread Index |