Subject: Re: statfs, statvfs and friends.
To: Christos Zoulas <christos@zoulas.com>
From: Jason Thorpe <thorpej@wasabisystems.com>
List: tech-kern
Date: 03/30/2004 22:11:26
--Apple-Mail-2--672928452
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed


On Mar 30, 2004, at 3:32 PM, Christos Zoulas wrote:

> 1. Q: what should be the old ones named __foostatfs20()?
>    A: I say yes since there is precedence of using the last OS version
>       supported them natively.

No, the precedent is to name the NEW ones __foostatfs13(), etc.  The 
signal stuff was an anomaly -- the intent was to use the libc major 
version that the new calls correspond to.

> 2. Q: Should we go all the way and implement statvfs()?
>    A: I think so. statfs() is a berkeleism.
>    2a. Q: If we supply statvfs(), then do we still supply statfs too?
>        A: Not sure.

If we go all the way and supply statvfs, then we don't need to bother 
versioning the old call at all.  Just let it continue to exist, and 
truncate the values that would overflow at 2TB.  Make the old call 
dependent on COMPAT_16.

>    2b. Q: X/Open says we should use unsigned long for bsize, frsize and
>           fsblkcnt_t for the rest. Should we do that?
>        A: I say keep the types as I have them.

If you're going to bother implementing statvfs (something defined by a 
standard), then use the types that the standard says.  Using fixed-size 
types is nice, but if it means that you technically do not comply with 
a standard, then I think it's foolish to be stubborn about it.

>    2c. Q: bsize in statfs() has been the fragment size; bsize in 
> statvfs()
> 	  is the block size, and frsize is the fragment size. Should we go
> 	  the statvfs() way.
>        A: I propose go that way too.

Agree... I think we should implement the standard.

         -- Jason R. Thorpe <thorpej@wasabisystems.com>


--Apple-Mail-2--672928452
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFAamETOpVKkaBm8XkRAschAKDMnHhT5IJE+kUiC8/autgmt7c9xwCg0Lw5
WqK1p0RB/l94bjaNE/WIzfo=
=++e5
-----END PGP SIGNATURE-----

--Apple-Mail-2--672928452--