Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 20 Mar 2013 20:56:39 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        John Baldwin <jhb@freebsd.org>
Cc:        arch@freebsd.org, gleb@freebsd.org, freebsd-arch@freebsd.org
Subject:   Re: Increase the mount path to MAXPATHLEN?
Message-ID:  <20130320185639.GI3794@kib.kiev.ua>
In-Reply-To: <201303200909.54555.jhb@freebsd.org>
References:  <20130319201145.GA19260@ambrisko.com> <20130320102116.GA3794@kib.kiev.ua> <201303200909.54555.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--7ny1L16MQneaJ3Er
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
> >=20
> > 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.
>=20
> 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 vector=
s.
> 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.

>=20
> However, it is true that in addition to new system calls, you now also ne=
ed
> to add new versions of the relevant functions via symbol versioning in li=
bc
> as well.

--7ny1L16MQneaJ3Er
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iQIcBAEBAgAGBQJRSgZnAAoJEJDCuSvBvK1BavEP/0RgDDnoqSNTW4D151xDO18F
9m4nOB0SiDTwvTXCGvqV2pu9fBaUuvlVd972y70iDAWiAHNxKkEBRRhbnyC6cyY2
sMs26Mrwjz4NUI2wu9rsonkRjEeITmmEyj7UgDVXFzsprjBEWx94eFZKLFV1M4CW
Fg15qlZKDl4xCCKiAhBHsrRXlUsnJdu73n6D6R+6Fc17G6Wtq3LMgkMMBJmqQ/v8
VeBRuDTC58l5pWy2SAJrDNW1ffl5T/uSfVg7jixq3uWvBDcy4QfW4I0pHY4JGhcH
9gxpNkBsV/P9G9im21WTbSEfRhrtDh0b1zBUgpmrN2VdRFe8uwp91bYAwPCAF3Dv
XGCPgG8RUGE1lF9l/qWiwokGH7Ui2UE8aAmn1Clr4ikMBgEBWCZ/Uu16L9vtw0MF
FNTJd5iFozIzfVghlylQ43eC4hyReg9rAiCo3Q92ny+bx+62lgHpdO9wmdAUMpcr
9vxzaQw6jYW19qPYy+UnKtALspcjYQEKP9BRqjpq9aTmTqb4idVO+82AOGNyQcJN
d18Dq9ywYm/dtsthHE3QdCf0apyJqgmA8TLz7YExNVyB2JP1IzKzepzAuTuH3x44
Kk+2sPlWcbIXybuGN/+rVYTSTrvuJwgWvx+qoKSKKI83nq0NF3d7zbIwoCRa6ajx
ORijeYfXEG9KZ2Qq/OLi
=2l5b
-----END PGP SIGNATURE-----

--7ny1L16MQneaJ3Er--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130320185639.GI3794>