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

[Konstantin Belousov]

On Thu, Jan 02, 2014 at 10:27:58PM +0100, Pawel Jakub Dawidek wrote:
> On Thu, Jan 02, 2014 at 03:13:08PM +0200, Konstantin Belousov wrote:
> > On Thu, Jan 02, 2014 at 11:49:04AM +0100, Pawel Jakub Dawidek wrote:
> > > I don't plan to provide alternative way to fetch the cap stuff. Well, I
> > > implemented libnv, which can be used to reimplement how we fetch all
> > > data like kinfo_file in a ABI friendly way, but I don't plan to modify
> > > this specific code myself.
> > I.e. you break something and decline to fix it, putting the burden on
> > somebody else.
> 
> That's a bit too far. I wasn't declining fixing a bug I introduced.
> I was declining implementing an improvement. That's two very different
> things. Chose your words more carefully and not only this time.
I read this as decline to fix the ABI breakage.  I am sorry.

> 
> > > 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.
> [...]
> 
> To address your statement that either entire ABI is stable or not and
> there is nothing in between. That's of course incorrect.
> 
> First of all, we, as a project, don't consider all existing interfaces
> as stable. This would be a suicide. There are plenty of private
> interfaces we must and we do break from release to release.
Yes.

> 
> There was at least one case, AFAIR, where we broke ABI because of a
> security issue.
> 
> I also think that breaking ABI on unused interfaces can be fine too.
Probably yes.

> 
> We don't support ABI compatibility with FreeBSD 1, no matter how close
> we are, and we had this discussion in the past.
Yes, backward compatibility is a practical feature, and as each practical
thing, it has its usefulness limits.  But, for active interfaces, it
is a binary state, and kinfo_file definitely falls into the active and
recent interfaces pool.

> 
> I'm also in opinion that even if one day we run out of spare fields in
> kinfo_* structures the FreeBSD project should not be terminated.
Sure, we provide the backward compat when we are unable to extend the
current interface.  This is routinely done with syscalls and sysctls.
See kinfo_ofile as the relevant example.

John also wrote about this.

> 
> Ok, let's be more constructive.
> 
> I can use existing spare ints. This would move the problem into the
> future and will break ABI for existing 10-RCs.
> 
> We can also investigate how huge breakage that is. The sysctl interface
> is not public API, so I don't believe we should be concerned by its
> direct consumers. We have two public interfaces for this:
> 
> libutil's kinfo_getfile(3) which has exactly one in-base consumer -
> libprocstat, so this change breaks procstat(1) and fstat(1).
It started from the report of valgrind breakage AFAIR.

> 
> > This is just awful breakage of _ABI_.  We cannot leave it as is,
> > unless we also claim that project gave up on ABI stability at all.
> [...]
> > My own opinion is that the kinfo change must be removed, and the bug
> > is so critical that another RC must be issued.
> 
> I personally don't consider it so awful and critical as you do, clearly,
> but I do recognize it as a problem. I'm happy to consume spares, which
> should fix compatibility with older releases at the cost of breaking
> compatibility with 10-RCs.  At least for i386 and amd64, not sure how
> using ints for uint64_t will work for other archs.
At the moment, only x86 is considered Tier-1, which we guarantee to have
stable ABI. From the inspection of the patch referenced in the followup
message, I think that other architectures should be fine too, but I did
not verified this.

> 
> I'll leave it for re@ to decide.

My opinion is that the patch should go into HEAD with the 3-day MFC track
to stable/10.  Then, it is up to re to decide indeed, my vote already
is to allow this for releng/10.0 and to have RC5, unfortunately.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20140103/e24df4f7/attachment.sig>