svn commit: r254524 - head/sys/sys

[Davide Italiano]

On Wed, Aug 21, 2013 at 5:30 PM, Andre Oppermann <andre at freebsd.org> wrote:
> On 20.08.2013 20:13, Davide Italiano wrote:
>>
>> On Tue, Aug 20, 2013 at 7:42 PM, Andre Oppermann <andre at 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.

Thanks,

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare