Increase the mount path to MAXPATHLEN?

[Konstantin Belousov]

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.

> 
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20130320/5138e37d/attachment.sig>