Source-Changes archive

[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 :-)

christos




Home | Main Index | Thread Index | Old Index