Date: Wed, 20 Mar 2013 09:09:54 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org Cc: Konstantin Belousov <kostikbel@gmail.com>, arch@freebsd.org, gleb@freebsd.org Subject: Re: Increase the mount path to MAXPATHLEN? Message-ID: <201303200909.54555.jhb@freebsd.org> In-Reply-To: <20130320102116.GA3794@kib.kiev.ua> References: <20130319201145.GA19260@ambrisko.com> <20130320102116.GA3794@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201303200909.54555.jhb>