On Wed, Aug 21, 2013 at 6:18 PM, Andre Oppermann <an...@freebsd.org> wrote: > 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
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 _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"