site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Thanks Vincent Best regards, Stauff__ On Aug 27, 2007, at 8:40 AM, Vincent Lubet wrote: Platon, Thanks, Vincent On Aug 26, 2007, at 2:19 PM, Platon Fomichev wrote: That's my lament is like this: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... 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. 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. 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. 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.. This email sent to site_archiver@lists.apple.com