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

[Pawel Jakub Dawidek]

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.

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

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.

We don't support ABI compatibility with FreeBSD 1, no matter how close
we are, and we had this discussion in the past.

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.

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

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

I'll leave it for re@ to decide.

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://mobter.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20140102/040a0344/attachment.sig>