Subject: Re: CVS commit: src
To: Mindaugas R. <rmind@NetBSD.org>
From: Bill Stouder-Studenmund <wrstuden@netbsd.org>
List: source-changes
Date: 01/29/2008 18:37:37
--NklN7DEeGtkPCoo3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 28, 2008 at 05:59:27PM +0000, Mindaugas R. wrote:
> yamt@mwd.biglobe.ne.jp (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;
> >=20
> > MAXCPUS can only be increased?  why?
>=20
> In time we would like to support more processors, not vice-versa :)
> I guess you do not want to depend on such assumption?
>=20
> > 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.
> > <...>
>=20
> True, this needs to be fixed...
>=20
> > > - Why silent truncation is wrong in this case?
> >=20
> > each truncated bits can be either 0 or 1.
> > how can you know which was intended?
>=20
> In truncated part would be CPUs whose numbers are >=3D MAXCPUS. System do=
es not
> support them, so it does not matter. Your concern is error instead silenc=
e?

No, the problem is how does a program we compile today correctly cope with=
=20
a world where the size is larger? Or how does a library compiled today=20
cope with a kernel and application that were built for a larger MAXCPUS.

=46rom what little I've been able to glean, you're repeating the mistake=20
made with file sets in select(). Don't.

> > > Are you suggesting CPUSET_SIZE to not depend on MAXCPUS?
> >=20
> > 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.
> >=20
> > - 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)
>=20

Take care,

Bill

--NklN7DEeGtkPCoo3
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQFHn+LxWz+3JHUci9cRAtl9AJ0VlfY5FAhNX/xsN3Fux9FOHPvjTACgjIt/
BAyhjMGy3Ok+Xps+xzG4Mlo=
=iZwH
-----END PGP SIGNATURE-----

--NklN7DEeGtkPCoo3--