Re: large ufs2 partitions and 'df'

On Tue, May 13, 2003 at 07:35:29AM -0700, Terry Lambert wrote:
> 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.

This is basically the same, if the one argument to the syscall is
the desired interface version. It is a bit more flexible, since
it is possible to replace or drop fields. Another effect is the
minimal size of the struct.

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

Right. It works because the kernel knows that there are just
two sizes or in other words interface versions. The version
in use was implied by the command.

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

I don't want to include the version number in the struct.
I want my app to request the version it was compiled for and
delegate the compatibility magic to either the kernel or same
translation function. As long as fields are only added, this
conversion is just the copyin you've done in your lock patch,
but it might be worse. E.g. the MNAMELEN limit is raised one day.

For the case new kernel, old binary everything is alright. The
conversion function could be part of COMPAT_FREEBSD5 or similiar.
Not working is the other case -- old kernel, new binary. Working
around that would require application/library support for
downgrading the stat version.

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

The idea was (almost) nobody is directly calling the syscall, but
the libc wrapper. This wrapper could catch the EINVAL case and call
a special conversion function.

Well, I thought about using dlopen(), which doesn't work for static.
But since we need just a single function only copying a few bytes
between two structures mmap() could work. Not sure...

I guess this is too complicated, the COMPAT_FREEBSD5 is much cleaner
and simpler.

-- Joerg

> 
> -- Terry