On Mar 30, 10:11pm, thorpej@wasabisystems.com (Jason Thorpe) wrote:
-- Subject: Re: statfs, statvfs and friends.

| 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.

ok.

| > 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.

The consensus is to version it, make statvfs the syscall and make a
libc wrapper for foostatfs().

| >    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.

Yes, I agree.

| >    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.

Fine.

christos