Re: Deadlock in My KEXT with NKE
Re: Deadlock in My KEXT with NKE
- Subject: Re: Deadlock in My KEXT with NKE
- From: Mike Smith <email@hidden>
- Date: Wed, 18 Feb 2004 00:18:44 -0800
On Feb 17, 2004, at 12:29 PM, Brian Bergstrand wrote:
The kernel socket environment is very different from userland, in
particular all communications are async in nature using the
socket.so_upcall. This function is called whenever there is data
available on a socket. For Darwin, you will already be under the
network funnel, but you must take care not to block inside the
callback. This means no mutex locks (spinlocks are ok) and no memory
allocations.
You also need to be prepared to receive no or less data than expected.
As
per my earlier message, this is not a great place to be if you're not
prepared
for things to be very much unlike Kansas.
Within the callback, you call soreceive() to get an mbuf chain. Mbuf
data can be accessed with m_copydata() (if you've preallocated a global
buffer -- remember, you can't allocate within the callback). You can
also get a direct ptr to each mbuf's data using the 'm_data' struct
member/define. However, you will need to manage the chain yourself,
whereas m_copydata() does that for you.
Actually, you should probably call mtod(). Leave the innards of the
mbuf alone.
= Mike
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.