Is ctl_enqueuembuf destructive?
Is ctl_enqueuembuf destructive?
- Subject: Is ctl_enqueuembuf destructive?
- From: Allan Hoeltje <email@hidden>
- Date: Mon, 15 Aug 2005 14:17:30 -0700
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.
Do I need to do an mbuf_dup on my original mbuf and ctl_enqueuembuf the
duplicate? If so then it seems that ctl_enqueuembuf is no more efficient
than ctl_enqueuedata.
-Allan
_______________________________________________
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