Re: mbuf flags

[Robert Swindells <rjs%fdy2.co.uk@localhost>]

christos%astron.com@localhost (Christos Zoulas) wrote:
>In article <20150301224043.879F530285B%ren.fdy2.co.uk@localhost>,
>Robert Swindells  <rjs%fdy2.co.uk@localhost> wrote:
>>
>>christos%astron.com@localhost (Christos Zoulas) wrote:
>>>In article <5298.1425184456%perseus.noi.kre.to@localhost>,
>>>Robert Elz  <kre%munnari.OZ.AU@localhost> wrote:
>>>>    Date:        Sun,  1 Mar 2015 00:16:51 +0000 (GMT)
>>>>    From:        Robert Swindells <rjs%fdy2.co.uk@localhost>
>>>>    Message-ID:  <20150301001651.D680E30285B%ren.fdy2.co.uk@localhost>
>>>>
>>>>  | Also, keeping everything aligned would require adding an extra hex digit
>>>>  | to every one which would make it less clear what had really changed.
>>>>
>>>>Add the extra digits in a separate (change nothing) commit first,
>>>>then your real change will be smooth, and still look nice.
>>>>
>>>
>>>I have this patch to add the extra link bits for FreeBSD compat needed
>>>for net80122...
>>
>>[snip]
>>
>>Ok, that still doesn't tell me which bit I should use though.
>>
>>In Kame, the flag I am adding came before the M_LINK ones, it seems
>>better to me to follow this pattern and move up the M_LINK[0-7] flags
>>by one bit. This would mess up your patch though.
>
>If you do that, you'll break binary compatibility...

I had thought that mbufs were kernel only. I guess I had forgotten
about rump.

>What's that flag?

The flag is M_NOTIFICATION, if it is set then a matching MSG_NOTIFICATION
flag is passed to userspace by recv*().

FreeBSD maps it to M_PROTO1 in their source but they don't seem to use it
in mbufs.

I hadn't spotted until now that we have M_PROTO1 as well as the
M_LINK? flags. We only seem to use M_PROTO1 in sys/net/if_bridge.c and
sys/netbt/hci_link.c.

>>I presume we would move the M_EXT_ flags up by 4 bits at some point too.
>>
>>I have modified mbuf.h to just contain the formatting changes:
>
>Fine, lets do the just the formatting changes first.
>FreeBSD uses M_PROTO1 -> M_PROTO11 in net80211 (which is M_LINK1-M_LINK11)...

I can wait.

I had been thinking of committing SCTP in two stages anyway, the core
stuff in netinet and netinet6 first then the userland and an extra
syscall later.

Robert Swindells