On 21.08.2013 17:59, Davide Italiano wrote:
On Wed, Aug 21, 2013 at 5:30 PM, Andre Oppermann <an...@freebsd.org> wrote:
On 20.08.2013 20:13, Davide Italiano wrote:
On Tue, Aug 20, 2013 at 7:42 PM, Andre Oppermann <an...@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
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
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
