Re: mbuf initialization macros

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 15 Apr 2016 11:42:22 +0900
    From:        Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>
    Message-ID:  <5710550E.4010406%iij.ad.jp@localhost>

  | Could you comment this patch?

I would make them static inline functions, rather than macros, so you
don't need to use "implementation" var names (not that it matters as
a macro arg) and avoid problems should someone, sometime later, use a
non-constant arg (m++ or something).

I would also (after an audit of the uses) add any fields that are
commonly set to something other than NULL/0/etc in the init, and make
those params to the function - if the example you showed is typical,
then for M_HDR_INIT() (which as a func would probably be m_hdr_init())
I'd add a type param (and move the mowner_init() call into the func,)
as I would expect that frequently code that does things this way is
likely to want a type that is not MT_DATA.

But only for those values are frequently set to something specific in the
current places where you would (eventually) replace inline code by a
macro/static_inline_func call.   (Doesn't need to be all cases, but a param
that everyone has to set, just because one place wants the field different
than default, would be annoying).

For M_PKTHDR_INIT() I'd add data & flags params to set m_data and m_flags.
That is: make the macro/func turn the mbuf into a pkhhdr, rather than just
init the pkthdr fields after that has already happened.

If any of the other m_pkthdr fields are often set to different than
the default values (most likely would probably be rcvif) make that a
param too - just like (probably) "type" for M_HDR_INIT().

kre