Re: mbuf huge macro nuking

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:  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@xxxxxxxxxxxxxxxx  *  bmilekic@xxxxxxxxxxx
:TECHNOkRATIS Consulting Services  *  http://www.technokratis.com/

    I'll get to the diff this weekend, before I really go heavy into the DEV
    work.

    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.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>