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...

[John Baldwin]

On Thursday, January 02, 2014 2:59:35 pm John-Mark Gurney wrote:
> Konstantin Belousov wrote this message on Thu, Jan 02, 2014 at 21:26 +0200:
> > 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 entries from 
> > > > > > _kf_ispare until it is sorted.
> > > > > 
> > > > > 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 one
> > > > > 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 that is
> > > > > designed to expand, but cannot be, because kinfo_file wasn't modified 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.
> > > 
> > > 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.
> 
> 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...
> 
> > > 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.
> > 
> > > 
> > > Of course the problem is that when we move to
> > > (ASN.1/libnv/ctf/YAML/JSON/XML/etc) we will break ABI compatibility too,
> > > or introduce tons of compatibility code that will rot...
> > 
> > I do not understand what are you trying to say.
> 
> 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?

*cough*  Ahem.

We've changed the ABI of kinfo_file once before already and supported
both just fine.  Please search for COMPAT_FREEBSD7 in kern_descrip.c.
In this case this works because the relevant sysctls use fixed nodes,
so you can add a new ABI by moving the names to the new numbers but
leaving the old nodes in place for the old ABI.  Shouldn't take a huge
amount of work for Pawel to bang out appropriate COMPAT_FREEBSD8 |
COMPAT_FREEBSD9 diffs for this.  OTOH, this breaks the ABI for existing
10.x binaries, so it needs to be done ASAP.  I don't know if any ports
use these sysctls directly (psutil might).  If so a recompile should
generally "fix" them to move them to the new ABI once it is in place.

(And yes, Pawel, since you are changing kinfo_file, this is your
responsibility to fix.)

-- 
John Baldwin