site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Thread-index: AcUplFnWyZH/+jT2SF+V3faHyChh9AADtfSw Thread-topic: struct dlil_if_flt_str Not sure if I asked the question clearly enough in my last post, but to rephrase the question - Can I manipulate the Ethernet header, and packet data using the data passed into my dlil_if_flt_str function, filter_if_input? I am just anxious because I do not want to spend a lot of development time 'barking up the wrong tree'. And also thanks to Justin too. You added some comment after my sending of my kudos to Josh. Carl

On Mar 15, 2005, at 11:10 AM, Justin Walker wrote:

And to add to Justin's comments with my own little plea...

If you are looking to implement a new media type, please don't use the frame_ptr. Leave the whole packet in the mbuf. This gives the inbound and outbound filters whole packets. This also sidesteps the problem of variable length headers. There is no reason to specify the frame_ptr separately.

If you think of using a frame_ptr and setting it to point somewhere other than space in the mbuf, please be aware of a few things. When you pass the packets off to the stack, the packets are queued. This means you can not allocate storage for the frame header on the stack. There is no notification to let you know when the stack is done with the frame header. In the current shipping stack, you could specify a function pointer to handle notification of the cluster for the mbuf being freed but that may not be available in the future.

-josh On Mar 15, 2005, at 11:10 AM, Justin Walker wrote:

On Mar 15, 2005, at 10:52, Josh Graessley wrote:

...

*frame_ptr points to the frame header. The driver is responsible for setting this pointer. For ethernet interfaces, this points to the ethernet header. It is passed as a ** so the filter may change where the value of the pointer. The header is usually set to point at the start of the packet in the mbuf. The mbufs data pointer is then moved to point to the data in the packet following the header.

On the output side, there is no frame_ptr because the the entire packet including the frame header is in the mbuf.

Yes. The mbuf stores the meat of the packet. On the outbound path, it stores the entire packet. On the inbound path, it store the entire packet, but the data pointer has been incremented past the packet header and the pointer to where the header starts is passed separately as the frame_ptr. There are no guarantees that the frame_ptr points to data in the mbuf, but that's how it's implemented, and any other implementation would be problematic, so that probably won't ever change.

I am adding the following note to the thread:

While Josh is correct in what he says, we designed this collection of mechanisms to deal with disparate media layers. The ethernet media (and those similar to it) make Josh's prediction likely, but if another media type rears its ugly head, it is possible that implementations may choose to provide frame headers and payloads in different buffer areas.

Since you (Carl) are implementing code that deals with media info, you will know the nature of the packets you are getting, but you should, none-the-less, be wary of making too many assumptions regarding "the right way" to implement, based on the way things currently work.

Cheers,

Justin

-- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Some people have a mental | horizon of radius zero, and | call it their point of view. | -- David Hilbert *-------------------------------------- *-------------------------------*

_______________________________________________ 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/jgraessley% 40apple.com

This email sent to jgraessley@apple.com

_______________________________________________ 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... This email sent to site_archiver@lists.apple.com