Date: Tue, 13 May 2003 19:54:48 +0200 From: Joerg Sonnenberger <joerg@britannica.bec.de> To: freebsd-current@freebsd.org Subject: Re: large ufs2 partitions and 'df' Message-ID: <20030513175448.GA12926@britannica.bec.de> In-Reply-To: <3EC102B1.98F81C77@mindspring.com> References: <200305112244.h4BMiFTh036221@beastie.mckusick.com> <20030513140828.GA12938@britannica.bec.de> <3EC102B1.98F81C77@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030513175448.GA12926>