-----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 | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.
participants (1)
-
Brian Bergstrand