Date: Wed, 1 Nov 2006 13:59:52 -0600 From: Brooks Davis <brooks@one-eyed-alien.net> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: freebsd-arch@FreeBSD.org Subject: Re: sysconf(3) extensions. Message-ID: <20061101195952.GB56970@lor.one-eyed-alien.net> In-Reply-To: <20061101194618.GT15861@garage.freebsd.pl> References: <20061101190606.GQ15861@garage.freebsd.pl> <20061101192457.GA56970@lor.one-eyed-alien.net> <20061101194618.GT15861@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
--TakKZr9L6Hm6aLOc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 01, 2006 at 08:46:18PM +0100, Pawel Jakub Dawidek wrote: > On Wed, Nov 01, 2006 at 01:24:57PM -0600, Brooks Davis wrote: > > On Wed, Nov 01, 2006 at 08:06:06PM +0100, Pawel Jakub Dawidek wrote: > > > Hi. > > >=20 > > > I'd like to add two non-standard value to the sysconf(3) functions, > > > which can be found in both Solaris and Linux: _SC_PHYS_PAGES and > > > _SC_AVPHYS_PAGES. > > >=20 > > > The patch is here: > > >=20 > > > http://people.freebsd.org/~pjd/patches/sysconf.patch > > >=20 > > > Can someone review it? Thanks. > >=20 > > What are they for? My concern is that _SC_AVPHYS_PAGES isn't going to > > semantically match other platforms since in a steady state the free cou= nt > > is small on FreeBSD, but on other systems it swings quite a bit based on > > load. >=20 > _SC_PHYS_PAGES is used by libzpool (a part of the ZFS file system). > _SC_AVPHYS_PAGES I used more for completness. OK. I'd be somewhat inclined to leave _SC_AVPHYS_PAGES out in that case, but I don't feel strongly about it. > > +Note that it is possible for the product of this value and the value of > > +.Li _SC_PAGE_SIZE > > +to overflow. > >=20 > > This would be more clear if it said what was expected to overflow and > > when. >=20 > The sysconf(3) functions return 'long' and on 32bit machine long is also > 32bit. If we have more than 4GB of memory (PAE) and want to calculate > physical memory in bytes doing _SC_PHYS_PAGES * _SC_PAGE_SIZE will > overflow. But I'm not sure if I want to put this into manual page... > Maybe as an example if there are or may be in the future other cases > when this is possible? That's the problem I expected. Actually since it's a long not a u_long, it would overflow at >2GB. Maybe something like: Note that it is possible that the product of this value and the value of =2ELi _SC_PAGE_SIZE will overflow a long in some configurations on a 32bit machine. My worry is that your original phrasing may be unnecessarily subtle. -- Brooks --TakKZr9L6Hm6aLOc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFSPy4XY6L6fI4GtQRAiGgAJ9jTNNmmmZ8YgYaJ9hHCsF/vUcVoQCfch4R en/4i4J+WLhajQmV9um7fZE= =UiNh -----END PGP SIGNATURE----- --TakKZr9L6Hm6aLOc--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061101195952.GB56970>