Re: Deadlock in My KEXT with NKE
Re: Deadlock in My KEXT with NKE
- Subject: Re: Deadlock in My KEXT with NKE
- From: Brian Bergstrand <email@hidden>
- Date: Tue, 17 Feb 2004 14:29:30 -0600
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Matt,
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.
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.
If you need to work in a less restrictive environment than the upcall
callback, you'll need to have a shared queue protected by a spinlock.
The upcall function would push a socket onto the service queue, and
then notify another thread that there is a socket on the queue. In the
other thread, you would pop a socket off of the queue and grab the
network funnel; then you can do anything you want with the socket
without the no-block restrictions necessary in the upcall callback.
For sending data, you need to copy the data to an mbuf chain, and then
call sosend() with the chain. sosend() will release the chain when all
the data has been sent. You are limited by the socket high-water mark
(socket.so_snd.sb_hiwat) for the amount of data that can be on the
chain.
I suggest you pick up a copy of the Wright/Stevens "TCP/IP Illustrated
Volume 2" book. It will help greatly with explaining how things work in
the kernel.
HTH.
On Feb 15, 2004, at 1:47 PM, Matt Jaffa wrote:
>
I think my program might be better off using sockets. From my daemon
>
to daemon testing of sockets, I really appreciate the power they have.
>
>
The only reason I am confused is because of the lack of documentation
>
on the Kernel side of sockets, etc.
>
>
Because with the daemon side of the socket the recv and send functions
>
are different than the sosend and sorecv of the Kernel side, the
>
arguments don't map to each other,
>
I know I am overlooking something, but say I wanted to send something
>
to the daemon that waiting on a recv? And the Daemon is set to recv
>
it in a buffer of a given size. In the sosend function there is mbufs
>
and aiov args that are confusing as how to get information to the recv
>
in the daemon which its arg is buffer and the size of buffer.
>
>
Matt
>
>
>
On Feb 15, 2004, at 12:49 AM, Mike Smith wrote:
>
>
> With the exception of client termination notification, I think Matt
>
> might be better off using sysctl. Sockets mostly just add overhead
>
> and confusion, especially if the developer doesn't appreciate the
>
> subtleties of their decoupled nature.
>
>
>
> = Mike
>
>
>
>
>
> On Feb 14, 2004, at 6:37 PM, Vincent Lubet wrote:
>
>
>
>> On Feb 14, 2004, at 2:58 PM, Matt Jaffa wrote:
>
>>
>
>>> I have been trying to implement this System control socket, but
>
>>> can't seem to get it to work, The problem is I don't know how to
>
>>> make sockets within the KERNEL connect up with the socket in my
>
>>> Daemon. I wan't the Daemon socket to act as the server and the
>
>>> KEXT socket to call out when it has work to do then wait to receive
>
>>> a message back. I can do this with AF_UNIX when it is daemon to
>
>>> daemon, but I can't get KEXT to daemon sockets to work.
>
>>>
>
>>> Do you know of any code out there that can demonstrate the KEXT
>
>>> connecting to a daemon socket?
>
>>
>
>> I do not know of any AF_UNIX code but the kernel NFS code shows how
>
>> to use sockets from the kernel.
>
>>
>
>> Using sockets in the kernel is pretty similar to using sockets in
>
>> user space except the function are different. The main point is you
>
>> cannot use select() and instead you should set the so_upcall with
>
>> the address of a function that gets the event notification.
>
>>
>
>> Basically this is what you should do:
>
>> 1) call socreate()
>
>> 2) set the so_upcall and associated field
>
>> 3) call soconnect() with the address of the deamon.
>
>>
>
>> Vincent
>
>
Brian Bergstrand <
http://www.bergstrand.org/brian/>, AIM: triryche206
PGP Key: <
http://www.bergstrand.org/brian/misc/public_key.txt>
The advertisement is the most truthful part of a newspaper. - Thomas
Jefferson
As of 01:55:27 PM, iTunes is playing "Wonderboy" from "Tenacious D" by
"Tenacious D"
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3
iQA/AwUBQDJrnHnR2Fu2x7aiEQJVtACg2EdXsspGudOBztRoeqfLbiU6j5UAoJ9K
g0hwfHBz6VtzkAuz3FRvZ2je
=VVH/
-----END PGP SIGNATURE-----
_______________________________________________
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.