Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 6 Jan 2005 12:07:18 -0800
From:      Brooks Davis <brooks@one-eyed-alien.net>
To:        Giorgos Keramidas <keramida@freebsd.org>
Cc:        freebsd-current@freebsd.org
Subject:   Re: human-readable swap partition sizes with pstat -sh
Message-ID:  <20050106200718.GD24896@odin.ac.hmc.edu>
In-Reply-To: <20050106195950.GA34916@gothmog.gr>
References:  <20050106191201.GA30826@gothmog.gr> <20050106195719.GB24896@odin.ac.hmc.edu> <20050106195950.GA34916@gothmog.gr>

next in thread | previous in thread | raw e-mail | index | archive | help

--MAH+hnPXVZWQ5cD/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 06, 2005 at 09:59:50PM +0200, Giorgos Keramidas wrote:
> On 2005-01-06 11:57, Brooks Davis <brooks@one-eyed-alien.net> wrote:
> > On Thu, Jan 06, 2005 at 09:12:01PM +0200, Giorgos Keramidas wrote:
> > > The following patch adds support for human-readable partition sizes in
> > > pstat -s and swapinfo output, when the -h option is used:
> > >
> > > 	gothmog:/d/src/usr.sbin/pstat$ ./pstat -s
> > > 	Device          1K-blocks     Used    Avail Capacity
> > > 	/dev/ad1s1b       5120000       12  5120000     0%
> > >
> > > 	gothmog:/d/src/usr.sbin/pstat$ ./pstat -sh
> > > 	Device          1K-blocks     Used    Avail Capacity
> > > 	/dev/ad1s1b       5120000      12K     4.9G     0%
> > >
> > > Does anyone have comments or suggestions for further improvement?
> >
> > Look good in general.  Does -kh make sense?  I think so since it would
> > force the blocks line, but I'm not 100% sure.
>=20
> It does.  -k only affects the way 'number of blocks' is printed.  The
> sizes of 'used' and 'avail' are calculated differently -- in bytes,
> otherwise humanize_number() would return bogus strings.
>=20
> > On minor, mostly style nit is that while intmax_t is 64-bits, nothing
> > requires that so you should probably have conver return an int64_t.
>=20
> I lost you a bit here.

The CONVERT macro used to case to (int).  You removed that cast which
works because humanize_number takes an int64_t and intmax_t is the same
as int64_t on all architectures.  I was suggesting that you should case
to int64_t.  Alternativly, humanize_number could be fixed.  I can't
think of any useful reason to add the complexity of 128-bit ints to
general purpose CPUs so this is probalby mostly paranoia.

-- Brooks

--=20
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4

--MAH+hnPXVZWQ5cD/
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFB3Zp1XY6L6fI4GtQRAt8EAJ0YiR4Wuj33U7y157h7Dqlnoa7xCwCgm6Ll
ebNVOFfDPyNowLGa68GQyBM=
=5jbp
-----END PGP SIGNATURE-----

--MAH+hnPXVZWQ5cD/--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050106200718.GD24896>