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]

Scott Long <scottl at freebsd.org> wrote:

> On Wed, 12 Nov 2003, Kirk McKusick wrote:> mckusick    2003/11/12 00:01:40 PST
> >
> >   FreeBSD src repository
> >
> >   Modified files:
> >     bin/df               df.c
> >     sys/kern             syscalls.master vfs_bio.c vfs_cluster.c
> >                          vfs_syscalls.c
> >     sys/sys              mount.h
> >     sys/ufs/ffs          ffs_vfsops.c
> >   Log:
> >   Update the statfs structure with 64-bit fields to allow
> >   accurate reporting of multi-terabyte filesystem sizes.
> >
> >   You should build and boot a new kernel BEFORE doing a `make world'
> >   as the new kernel will know about binaries using the old statfs
> >   structure, but an old kernel will not know about the new system
> >   calls that support the new statfs structure. Running an old kernel
> >   after a `make world' will cause programs such as `df' that do a
> >   statfs system call to fail with a bad system call.
> >
> 
> Kirk,
> 
> Thanks a lot for getting this in.  Can you send a HEADS-UP email to the
> lists (freebsd-current especially) just to make sure people understand the
> implications?

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.                       \,,,,,,,,,,,,,,,,,,,,,,\