Date: Thu, 2 Jan 2014 23:27:00 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: John-Mark Gurney <jmg@funkthat.com> Cc: src-committers@FreeBSD.org, Pawel Jakub Dawidek <pjd@FreeBSD.org>, svn-src-all@FreeBSD.org, Alfred Perlstein <bright@mu.org>, Stanislav Sedov <stas@FreeBSD.org>, svn-src-head@FreeBSD.org Subject: Re: svn commit: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensola... Message-ID: <20140102212700.GO59496@kib.kiev.ua> In-Reply-To: <20140102195935.GC99167@funkthat.com> References: <201309050009.r8509vsE061271@svn.freebsd.org> <67DFFD7B-01DE-4862-BED3-DD42EB92A8F4@freebsd.org> <20140102093322.GA1655@garage.freebsd.pl> <52C53F69.3040507@mu.org> <20140102104904.GB1655@garage.freebsd.pl> <20140102131308.GI59496@kib.kiev.ua> <20140102191420.GB99167@funkthat.com> <20140102192612.GM59496@kib.kiev.ua> <20140102195935.GC99167@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--XzkEUK0ZpyGWSJtg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 02, 2014 at 11:59:35AM -0800, John-Mark Gurney wrote: > Konstantin Belousov wrote this message on Thu, Jan 02, 2014 at 21:26 +020= 0: > > On Thu, Jan 02, 2014 at 11:14:20AM -0800, John-Mark Gurney wrote: > > > Konstantin Belousov wrote this message on Thu, Jan 02, 2014 at 15:13 = +0200: > > > > > > Afaik you could just remove the "spare" and steal 2 or 4 entrie= s from=20 > > > > > > _kf_ispare until it is sorted. > > > > >=20 > > > > > Yes, this would work for current cap_rights_t structure, at least= for > > > > > i386 and amd64, but would only allow to expand the structure by o= ne > > > > > uint64_t in the future (which might or might not be enough). The > > > > > cap_rights_t structure is designed to be expanded to 5 uint64_ts = without > > > > > breaking ABI. I don't want to stuck with current cap_rights_t tha= t is > > > > > designed to expand, but cannot be, because kinfo_file wasn't modi= fied at > > > > > the start of a major branch. > > > > The ABI stability is not limited to the single branch. It must be > > > > preserved across whole project lifetime. > > >=20 > > > Umm. when did this policy change happen? I thought ABI compatibility > > > was limited to major releases of FreeBSD? How are you suppose to do > > > any work if you can't break ABI ever? > > Policy did not changed. Breaking ABI was never allowed, except for the > > kernel management interfaces. Later was only accepted due to tight > > relation of the typical management facilities and internal kernel > > structures, but this is considered a bug. >=20 > Please do no use such absolutes, since the ABI has been allowed to break > in the recent past, as I'm looking at a commit in 2005 that broke struct > kproc_info size... 'Allowed' is wrong term. Correct term is 'bug'. ABI bugs are special because we cannot fix them, due to impact lasting forever in the infected binaries. For kernel panic, you update kernel; for interface breakage, you have no exit strategy, either old or new binaries are broken. >=20 > > > I did a quick search for "freebsd policy abi breakage" and found some > > > mailing list posts about this, but no authoritative statement... > > Re tried to write down the policy, last time it was several years ago. > > The efforts should be revived. > >=20 > > >=20 > > > Of course the problem is that when we move to > > > (ASN.1/libnv/ctf/YAML/JSON/XML/etc) we will break ABI compatibility t= oo, > > > or introduce tons of compatibility code that will rot... > >=20 > > I do not understand what are you trying to say. >=20 > My point is that once we move to the "new ABI", we will either have to > accept that we stop maintaining the old interface, or we write and > maintain the old interface, but if we do, what's the point of going to > the new interface if the old interface "never" breaks? Point of providing the old interface is to allow old binaries to still work, or degrade in controlled and safe way. --XzkEUK0ZpyGWSJtg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSxdmjAAoJEJDCuSvBvK1BfJAP/3M9cXvADEhpMGdVJeNnoyU5 CHhkkLCRl3oVzIGI/3+Ch3m53DUMBEbCzYfygwVBim83Bzgz3HT5r/J9s7iLKAfC 1yyXZNUyWPo2HOYRXepDPgVLgqd3p1fPg59OTGxwqnOX0kYMzfIzjySOpXWj86X6 L/MHY3wHUNk0h5VzrUnGbt6ODL/eda9JDlaYgHUwMgxEBDfhsPnCRhiozXKd1THd GwmZMLTijZVV9UohDb1KVlsS9oBkDYqbNdewLDAALq9PUiNWmDYfbxQOww86nizo FY/4IyOgPbzInf/9aSiDyhgzTjfiXtYGMPuqvlNtBWmy3//4dK7szZ3pdSkzhyw/ FGvQAor+ns3B9TqRjOIHkmkLBVtECbANrYrkyHWmjnIx7J1rvtFqiGGMP8zTn09C XjxKIG+wsBIPwAgip8nNdglnYLEYaHwbF+3ALkY3nCHntlP9TOmwE6yzvEQPX1w+ /IgJ8aYMllJ2p1ssPuZH+ch/6RbmXoDOcE0hs/bM5Wl6gUNLtMNz300Pj5ZRxjfp zcKlXLZdIASp+TyviUjK+xwBLDnECyzmScrT1En3++nPgVIqhoC6wlrLgnf8axrx 4uwnd1eti7TtLfrgVNNm709QbonDC/zfNnjm7XF5lVQGnSDuuwpYfsUJyY3m3B81 mJxSd8U5bAWlV3LcgdoQ =wd9m -----END PGP SIGNATURE----- --XzkEUK0ZpyGWSJtg--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140102212700.GO59496>