Date: Wed, 01 Nov 2000 21:16:59 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Marcel Moolenaar <marcel@cup.hp.com> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, freebsd-current@FreeBSD.ORG Subject: Re: linux emulation Message-ID: <22796.973109819@critter> In-Reply-To: Your message of "Wed, 01 Nov 2000 15:08:24 EST." <3A007838.25121ACC@cup.hp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <3A007838.25121ACC@cup.hp.com>, Marcel Moolenaar writes: >Poul-Henning Kamp wrote: >> >> >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 ? > >Correct. > >> 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 >[snip] > >It won't always work. Will will most often not work. >> 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) > >I think we should try to return the right statistics in the case where >we have it wrong now instead of returning the wrong statistics in the >case where we have it right now. OK. So, where do the programs that call this syscall have the udev_t from ? Do they know it to be a mountpoint ? Do the know it to be a bmajor or cmajor style udev_t ? Being Linux they only know one kind, right ? In that case, makebdev() has been wrong ever since we changed to mount cdevs in FreeBSD. You should simply change the makebdev() to makedev() and VBLK to VCHR in the vfinddev() right after. It's still mightily bogus though... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?22796.973109819>