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

[Brian F. Feldman]

"Poul-Henning Kamp" <phk at phk.freebsd.dk> wrote:
> 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.

See, by "block ENOSYS", I sorta meant to say "block SIGSYS"... Still this 
seems like it would be a useful enough upgrade path for -current users if 
implemented soon.


-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green at FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\