Re: large ufs2 partitions and 'df'

User Joerg wrote:
> On Mon, May 12, 2003 at 07:53:49AM -0700, Terry Lambert wrote:
> > If you're going to change the structure, please put a version
> > number as the first field, so that it's never a problem again.
> >
> [...]
> 
> Why don't you do it the other way around? In my understanding
> the problem is kernel <-> user mode compatibility. If the syscall
> itself takes the version number, the kernel has the following
> possibilities:
> - it's the native struct stat -> perfect
> - it's a supported older version -> convert / fill only needed fields
> - otherwise, return EINVAL or similar

I was thinking in terms of the technique I used here:

	http://people.freebsd.org/~terry/DIFF.LOCKS

These are patches that seperate the locking namespace by adding
a system ID parameter to prevent coelescing of locks belonging
to processes on other systems, and to allow specification of a
PID for the remote system.  The patches themselves are rather
dated vs. -current at this point, but they are pretty self
explanatory, if you only look at the top of the patch, and
ignore the delayed coelescing that it also adds.

The net effect is that I'm able to use a different structure
size on the copyin/copyout, based on the argument to the kernel
function.


> If you now add a special version number 0 to query the stat version
> of the kernel, you can add a user level conversion function to
> catch those EINVAL cases. This would be necessary for cases like
> new userland and old kernel. This function might be loaded via dlopen.

I'm much less concerned with preventing someone from calling
a kernel function with a newer/older structure than I am with
making the code still work when it happens.  Particularly an
older binary on a newer kernel.

The code in the example above is able to maintain its binary
backward compatability because the new and old structures can
be overlaid, and the expansion area is at the end of the
structure, instead of in the middle somewhere, and because it
uses the command argument as a sort of version number, in and
of itself.  Without the complete separation of the command
namespace (automatic, in the example), I would have needed a
version number there, too.

Because of the spare fields in the middle in this case, you
will need a version number in the structure to maintain
binary backward compatability.  Effectively, this makes the
version number a key field that indicates usage of the
spare fields in the middle.


> You might even drop the kernel support for old versions and just
> provide that special shared object especially for statically
> compiled apps.

This would work, if everything were linked shared, and no
one cared about binary backward compatability.

-- Terry