Date: Wed, 21 Aug 2013 18:29:04 +0200 From: Davide Italiano <davide@freebsd.org> To: Andre Oppermann <andre@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Navdeep Parhar <np@freebsd.org> Subject: Re: svn commit: r254524 - head/sys/sys Message-ID: <CACYV=-HAuqowTPvR5PZWhFTf_XQzEgmwxGUqF9mRhy_9nGqy-A@mail.gmail.com> In-Reply-To: <5214E86F.1060102@freebsd.org> References: <201308191356.r7JDuELE075073@svn.freebsd.org> <521257E2.4020502@FreeBSD.org> <5213AAA1.6020700@freebsd.org> <CACYV=-F2YQUe3SamyfwBPFpDKcMbsQ35kX26qVDWcaessjj=JA@mail.gmail.com> <5214DD31.6010205@freebsd.org> <CACYV=-EfM5Vu7NCTe3gkMRtyqgf0ZhZagGp6HkB%2BWRE8yLX_2g@mail.gmail.com> <5214E86F.1060102@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Aug 21, 2013 at 6:18 PM, Andre Oppermann <andre@freebsd.org> wrote:
> On 21.08.2013 17:59, Davide Italiano wrote:
>>
>> On Wed, Aug 21, 2013 at 5:30 PM, Andre Oppermann <andre@freebsd.org>
>> wrote:
>>>
>>> On 20.08.2013 20:13, Davide Italiano wrote:
>>>>
>>>>
>>>> On Tue, Aug 20, 2013 at 7:42 PM, Andre Oppermann <andre@freebsd.org>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 19.08.2013 19:37, Navdeep Parhar wrote:
>>>>>>
>>>>>>
>>>>>> Why reuse the freed up bits so soon (at least one of which I think was
>>>>>> prematurely GC'ed -- see my other email on M_NOFREE). There was room
>>>>>> beyond M_HASHTYPEBITS, no?
>>>>>
>>>>>
>>>>>
>>>>> This is HEAD where kernel and modules have to be (re)compiled together
>>>>> at any point in time. On stable this reuse would not have been
>>>>> possible.
>>>>>
>>>>> In a subsequent commit I compacted and ordered the flags. There's a
>>>>> couple
>>>>> of free ones remaining.
>>>>>
>>>>> I have some additional mbuf changes coming up to be posted for possible
>>>>> objections later today. The close HEAD freeze deadline has got me
>>>>> rushed
>>>>> a bit to allow 10.x backporting of the checksum/offload overhaul.
>>>>>
>>>>> --
>>>>> Andre
>>>>>
>>>>
>>>> In my opinion the possibility we have about breaking KPI/KBI should
>>>> not be abused, even if it's allowed in HEAD. In other words,people
>>>> should go for preserving it when (as in this case) it's easy and
>>>> without additional costs. Your point about "this is HEAD, it can be
>>>> broken at any time" makes relatively little sense to me. Note that in
>>>> the worst case such KPI/KBI breakages are annoying for $VENDORS who
>>>> maintain out-of-tree code, which need to rebuild/change their code,
>>>> or, if they get pissed off, drop FreeBSD support.
>>>> In your case, it's just a matter of "code cleaness" about few lines,
>>>> which, IMHO and always IMHO, doesn't justify the breakage.
>>>
>>>
>>>
>>> Preserving the API but having to recompile is always fair game in HEAD.
>>> In fact it happens all the time and the only supported way to track HEAD
>>> is to recompile kernel and modules together.
>>>
>>> For removing (crufty) functionality I agree that it shouldn't be done
>>> just for the sake of it and also shouldn't be done often. Sometimes it
>>> is necessary in the name of progress. Having to support old, crufty or
>>> broken ways of doing something is a waste of developer time too.
>>>
>>> It's always a judgement call. In this case there is a perfectly valid
>>> alternative way of doing that also is less dangerous to leak mbufs.
>>>
>>> --
>>> Andre
>>>
>>
>> I don't see in any way how flags reordering might be in any way
>> connected to mbufs leaks, alas.
>> There's a similar recent('ish) discussion and it was decided to not
>> compact/reorder flags. See r253662/r253775 for references.
>> So, I'm not sure what's the de-facto policy, but still, as a community
>> FreeBSD should decide one strategy and be stuck with that. It's a
>> matter of being consistent, which, IMHO, is something that should not
>> be undervaluated.
>
>
> I fail to see what problem you have with the flag reordering. Recompile
That it broke KBI. Without any advantage, other than "compacting"
things and making code a bit more readable.
And without any real reason, as there's still room for new flags. I
think Navdeep pointed out this as well. But I won't object anymore. Go
for it. The reason why I replied is that I find silly doing something
like this without real advantage.
> and done. That's why we work with #defines instead of magic 0x1234 values.
> If someone outside the tree was using the spare bits for their own private
> purposes, yes, they would quickly have to check and possibly adjust them.
> That's trivial however and should be expected when tracking an OpenSource
> operating system. If you want total ABI stability then build on Windows
> but even they made a big break somewhere around NIDS5 or NDIS6. We can't
> get stuck on every bit because there may be someone somewhere out there
> we don't know about using it. On any x-stable such a reorder wouldn't
> be possible obviously because of the ABI preservation guarantee.
>
> --
> Andre
>
Thanks,
--
Davide
"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACYV=-HAuqowTPvR5PZWhFTf_XQzEgmwxGUqF9mRhy_9nGqy-A>