mbuf huge macro nuking
dillon at apollo.backplane.com
Fri Jul 18 20:56:42 PDT 2003
: I don't really know. FWIW, the submitted diff is not a
: style-change. It is a functional change aimed at reducing code cache
: pollution. I have not changed the API. If you want to persue this,
: you can continue this change and get rid of MCLALLOC and implement
: m_clget() (basically, see FreeBSD's HEAD).
: Renaming flags may be premature at this point. The bikeshed
: surrounding the changing of the M_* names and everything in relation
: to that has been less than enjoyable in my experience. On that note,
: I guess that I'm rather purposely passive regarding the issue. In
: other words, generate the diff and submit it and if Matt likes it and
: thinks it's the right time, he'll commit it. In the meantime, for the
: love of G-d, let's not get into this debate again [here].
:Bosko Milekic * bmilekic at xxxxxxxxxxxxxxxx * bmilekic at xxxxxxxxxxx
:TECHNOkRATIS Consulting Services * http://www.technokratis.com/
I'll get to the diff this weekend, before I really go heavy into the DEV
I've said this before but I am all for cosmetic changes which make the
code more understandable. It's actually a nice break for me to review
and commit things like that. In that light I would accept an M_ name
changing patch and would suggest that the mbuf code's M_ flags be changed
rather then the malloc code's M_ flags. I would also accept patches
which remove the 'register' keyword, and the __P() junk.
It is my position that code trees have diverged so much (even just between
FreeBSD-4 and FreeBSD-5) that cosmetic changes will not make backporting
any more or less difficult. We should attempt to ensure that backported
code doesn't accidently compile the wrong constants in (i.e. I would rather
the compiler generated an error for the incompatibilities so we know what
to fix), but that's pretty much the only issue I have.
<dillon at xxxxxxxxxxxxx>
More information about the Submit