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

[Poul-Henning Kamp]

In message <200311122219.hACMJwaG007327 at beastie.mckusick.com>, Kirk McKusick wr
ites:
>	From: "Brian F. Feldman" <green at FreeBSD.org>
>	Date: Wed, 12 Nov 2003 14:16:07 -0500
>	Sender: owner-src-committers at 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 at 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.

Uhm, as far as I recall, calling an undefined system call gives you
a signal you need to handle, before you will ever see the ENOSYS.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at 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.