Re: mbuf_pullup practically useless
Re: mbuf_pullup practically useless
- Subject: Re: mbuf_pullup practically useless
- From: Platon Fomichev <email@hidden>
- Date: Mon, 27 Aug 2007 11:25:48 +0400
Thanks Vincent
I will surely do this. Btw as a side note questions - are there any
plans to include OpenBSD Packet Filter (quite a good piece of
software imho) into Mac OS? I am thinking of doing some initial
investigations on possibility of this project if no-one is already on
this.
As another side-note I am constantly in question why does ./configure
like scripts take an exceptionally big amount of time on even most
powerful Mac Pro's compared to FreeBSD? Is this related to fork()/exec
() or sh port itself or something else? Anyone ever did some research
on this?
As the last one note (possibly offtopic sorry) - I am curious why
ASMx86 SHA1/MD5, etc optimizations are not present in OpenSSL in Mac
- they are considered to be rock solid and give a tremendous amount
of improvements on any x86 macintosh.
Best regards,
Stauff__
On Aug 27, 2007, at 8:40 AM, Vincent Lubet wrote:
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