Re: CVS commit: src

["Mindaugas R." <rmind%NetBSD.org@localhost>]

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?

> > Are you suggesting CPUSET_SIZE to not depend on MAXCPUS?
> 
> i'm suggesting to make it dynamic at least for userland programs.
> 
> - 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)

OK, we can use syscall or perhaps sysconf(_SC_CPUSET_SIZE) for schedctl(8)
and suggest to use that in manuals. However, I want to keep the compatibility
with Linux, they use: sched_setaffinity(pid, sizeof(cpuset_t), &set);

-- 
Best regards,
Mindaugas
www.NetBSD.org