FW: struct dlil_if_flt_str
FW: struct dlil_if_flt_str
- Subject: FW: struct dlil_if_flt_str
- From: "Carl Smith" <email@hidden>
- Date: Tue, 15 Mar 2005 16:17:24 -0500
- 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 (email@hidden)
> Help/Unsubscribe/Update your Subscription:
> 40apple.com
>
> This email sent to email@hidden
_______________________________________________
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