From owner-freebsd-arch@FreeBSD.ORG Wed Mar 20 22:00:47 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C0B7D45C; Wed, 20 Mar 2013 22:00:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9BE5E7C3; Wed, 20 Mar 2013 22:00:47 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EA053B917; Wed, 20 Mar 2013 18:00:46 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Subject: Re: Increase the mount path to MAXPATHLEN? Date: Wed, 20 Mar 2013 18:00:37 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <20130319201145.GA19260@ambrisko.com> <201303200909.54555.jhb@freebsd.org> <20130320185639.GI3794@kib.kiev.ua> In-Reply-To: <20130320185639.GI3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201303201800.38090.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 20 Mar 2013 18:00:47 -0400 (EDT) Cc: arch@freebsd.org, gleb@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 22:00:47 -0000 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@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