Re: Is ctl_enqueuembuf destructive?
Re: Is ctl_enqueuembuf destructive?
- Subject: Re: Is ctl_enqueuembuf destructive?
- From: Vincent Lubet <email@hidden>
- Date: Mon, 15 Aug 2005 14:38:23 -0700
On Aug 15, 2005, at 2:17 PM, Allan Hoeltje wrote:
I want to send IP packets from my kext to a client app. Up to now
I've been
making a copy of the mbuf data with mbuf_copydata and then sending
the data
to the client with ctl_enqueuedata.
Today I looked at the source for ctl_enqueuedata and saw that it
takes my
flat data and copies it into a newly allocated mbuf which is then
passed to
sbappend and sbcompress.
So, it seemed to me that I could be more efficient if I just used
ctl_enqueuembuf to send the original mbuf to the client. However,
when I do
that I get the Grey Screen of Death.
I noticed that ctl_enqueuedata allocates a new mbuf but does not
free it.
Should I assume that sbappend causes the mbuf to be freed? If so,
then
calling ctl_enqueuembuf would also cause the original mbuf to be
freed,
right? It would certainly explain the GSofD. The source for
sbcompress
seems to indicate that it does free the mbuf space but I am not
sure if I am
reading m_free correctly.
This is correct, ctl_enqueuembuf consumes the mbuf
Do I need to do an mbuf_dup on my original mbuf and ctl_enqueuembuf
the
duplicate?
Yes you need to duplicate the mbuf if you plan to use it after
calling ctl_enqueuembuf.
If so then it seems that ctl_enqueuembuf is no more efficient
than ctl_enqueuedata.
I don't believe one is much more efficient than the other.
Vincent
_______________________________________________
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