Date: Wed, 12 Nov 2003 14:19:58 -0800 From: Kirk McKusick <mckusick@beastie.mckusick.com> To: "Brian F. Feldman" <green@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/bin/df df.c src/sys/kern syscalls.master vfs_bio.c vfs_cluster.c vfs_syscalls.c src/sys/sys mount.h src/sys/ufs/ffs ffs_vfsops.c Message-ID: <200311122219.hACMJwaG007327@beastie.mckusick.com> In-Reply-To: Your message of "Wed, 12 Nov 2003 14:16:07 EST." <200311121916.hACJG7ok002154@green.bikeshed.org>
next in thread | previous in thread | raw e-mail | index | archive | help
From: "Brian F. Feldman" <green@FreeBSD.org> Date: Wed, 12 Nov 2003 14:16:07 -0500 Sender: owner-src-committers@FreeBSD.org X-Loop: FreeBSD.ORG Does this mean someone may be free to write wrappers that block ENOSYS, execute statfs calls, and fall back to ostatfs calls (translating 64->32 bit values as best as possible, like the kernel does) returning the new statfs? Obviously, this would just be to add a safety window for the transition period and to be removed before a -RELEASE. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ The above would certainly be possible. If this were a more heavily used interface (like say stat), it would be a useful exercise. But I do not feel it is really necessary for statfs. However, I am not going to object if someone wants to go through the exercise of implementing your suggestion. Kirk McKusick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311122219.hACMJwaG007327>