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

Alfred Perlstein bright at mu.org
Thu Jan 2 19:45:33 UTC 2014


On 1/2/14, 11:34 AM, Konstantin Belousov wrote:
> On Thu, Jan 02, 2014 at 11:23:55AM -0800, Alfred Perlstein wrote:
>> On 1/2/14, 11:14 AM, 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?
>>>
>>> I did a quick search for "freebsd policy abi breakage" and found some
>>> mailing list posts about this, but no authoritative statement...
>>>
>>> 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 agree, however there is a very easy way to fix it for the time being.
>> Let's not be binary about it "well it's going to have to break, so let's
>> break it!" when such an easy way to not break it exists.  It should be
>> "let's see if there's a non-intrusive way of not breaking it" and the
>> answer to that seems to be "yes".
> If parts of ABI is broken, then why spend efforts trying to keep other
> parts stable ?  You already have random set of binaries broken, sometimes
> in subtle way.  Then, making other interfaces stable is just a waste.
>
> ABI stability is a yes/no proposition, you cannot have it partly done.
> Personally, I do not want to spend a time on hobbyist system.
>
> BTW, to point out obvious thing, Linux has almost perfect ABI stability
> and forward compatibility.  It is pity to see that our people do not
> understand the importance and benefits of it.
I agree strongly.

-Alfred


More information about the svn-src-all mailing list