In message <[EMAIL PROTECTED]>, Marcel Moolenaar writes:
>Poul-Henning Kamp wrote:
>> 
>> I was just looking at that piece of code, and I couldn't entirely
>> make out what it was even trying to do.  Can somebody more
>> linuxolator savy explain what the function linux_ustat() should
>> produce.
>
>The following comment explains what linux_ustat should do:
>
>       /*
>        * lu.f_fname and lu.f_fpack are not used. They are always zeroed.
>        * lu.f_tinode and lu.f_tfree are set from the device's super block.
>        */
>
>linux_ustat fills in a structure with the above mention fields. The
>meaning of f_tinode and f_tfree are explained by the following two
>statements:
>
>               lu.f_tfree = stat->f_bfree;
>               lu.f_tinode = stat->f_ffree;
>
>In short: given the (u)dev_t, get the FS statistics and return the
>number of free blocks and inodes of the FS on that device.

But the udev_t is a (32bit truncated to) 16bit one, right ?

In that case it will usually not work:

crw-r-----  1 root  operator  116, 0x00010002  1 Jan  1970 /dev/ad0
crw-r-----  1 root  operator  116, 0x00020000  1 Jan  1970 /dev/ad0s1a
crw-r-----  1 root  operator  116, 0x00020001  1 Jan  1970 /dev/ad0s1b
crw-r-----  1 root  operator  116, 0x00020004  1 Jan  1970 /dev/ad0s1e
crw-r-----  1 root  operator  116, 0x00020005  1 Jan  1970 /dev/ad0s1f
crw-r-----  1 root  operator  116, 0x00030002  1 Jan  1970 /dev/ad0s2c
crw-r-----  1 root  operator  116, 0x00040000  1 Jan  1970 /dev/ad0s3a
crw-r-----  1 root  operator  116, 0x00040003  1 Jan  1970 /dev/ad0s3d

Considering the fact that we were likely to return statistics for the
wrong filesystem with the old code, and most likely cannot return 
the right statistics anyway, I think we should just return zero
for those values (or some other more sensible values)

--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to