site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com 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... 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