Re: mbuf_pullup practically useless
Re: mbuf_pullup practically useless
- Subject: Re: mbuf_pullup practically useless
- From: Vincent Lubet <email@hidden>
- Date: Sun, 26 Aug 2007 21:40:35 -0700
Platon,
We -- Apple engineers lurking on the darwin mailing list -- really do
appreciate suggestions like yours.
The best way to make sure your enhancement request does fall through
the crack is to file a problem report at http://
bugreporter.apple.com/ so that it track into Apple's bug tracking
database. To ensure the problem report is routed to the correct
component you can always send a note to the mailing list with the
problem ID number.
Thanks,
Vincent
On Aug 26, 2007, at 2:19 PM, Platon Fomichev wrote:
This is more or less a generic lamentation not a question. I've
been doing quite a lot of KEXT coding recently (NKE mostly
interface filter) and thus I had to analyze packets. One of the
functions that I've used was mbuf_pullup. Here's its description:
Move the next len bytes in to mbuf from other mbufs in the chain.
This is commonly used to get the IP and TCP or UDP header
contiguous in the first mbuf. If mbuf_pullup fails, the entire mbuf
chain will be freed.
And I used it exactly for that - to get IP/TCP(UDP) header
contiguous in the first mbuf. To my surprise it turned out that
about 5-10% mbufs can't be pulled-up as they have something like
<--160 bytes leading space-->data-ptr<10 bytes used><2 bytes free>.
In such case pulling up will not fail but will not be correct
either - I even can't get a complete IP header (not speaking about
TCP/UDP)! I checked kernel sources and it seems that developers
think exactly the same - they do not pullup - instead they create a
copy of the header with the help of mbuf_copydata and stack
allocated data.
That's my lament is like this:
May be mbuf_pullup can be enhanced with some flag to actually move
data_ptr to the beginning of leading space, copy data and only
after that do a pullup?
May be an additional mbuf API can be added that can consume leading
bytes and move data to the mbuf beginning?
Also I am interested in smth. like this - if for example I will
write such a routines - can I submit them to Apple? If they will
accept them will they appear in next OS release or at some fix level?
I also have some additional thoughts on NKE implementation based on
the NDIS driver development for Win32 and now Mac - anyone from
Apple interested to hear?
I am new to this list, so I don't know the politics - whether Apple
kernel devs at least browse it, but judging from some mails
recently I guess they do..
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden