Increase the mount path to MAXPATHLEN?

[John Baldwin]

On Wednesday, March 20, 2013 2:56:39 pm Konstantin Belousov wrote:
> On Wed, Mar 20, 2013 at 09:09:54AM -0400, John Baldwin wrote:
> > On Wednesday, March 20, 2013 6:21:16 am Konstantin Belousov wrote:
> > > On Tue, Mar 19, 2013 at 01:11:45PM -0700, Doug Ambrisko wrote:
> > > > I have a patch at:
> > > > 	http://people.freebsd.org/~ambrisko/statf.patch
> > > > that people can glance at.  If this approach is the right way to go
> > > > then I update it for the latest -current and update it.
> > > 
> > > No, I do not think this is the right approach.
> > > You are breaking the ABI in the backward-incompatible way.
> > >
> > > What should be done is versioning the fstatfs(2) and other related
> > > symbols from libc. Please look at the lib/libc/include/compat.h
> > > and its use for upgrading the syscalls ABI.
> > 
> > Not sufficient.  This will not help static binaries or binaries using an
> > older libc (such as libc.so.6) if that libc used these system call vectors.
> > I know we rototilled all the stat system calls for 64-bit ino_t recently,
> > not sure if that also affected statfs.  If it did then you might be off
> > the hook for libc.so.6, but static binaries still matter as long as we
> > ship a libc.a.
> I do not see why. Old static binaries, as well old libc.so.6 and libc.so.7,
> would use old syscall numbers. New libc.so.7 use new syscall number, but
> export fstatfs at FBSD_1.0 which is resolved for the old binaries, resulting
> in old binaries calling old syscall.

Right.  I thought you were objecting to his adding new system calls and wanted
to only add wrappers in libc where the compat symbols in libc called the new
system calls and thunked the data.
 
> > However, it is true that in addition to new system calls, you now also need
> > to add new versions of the relevant functions via symbol versioning in libc
> > as well.

I guess you were just saying that Doug needs this additional step, and I concur
with that entirely.

-- 
John Baldwin