February 2004 - Darwin-kernel

Re: IPC with Sockets
by Matt Jaffa 21 Feb '04

21 Feb '04

Well I have discovered the cost of having to do that In my system log where it logs the KEXT's current condition, I am noticing that since there are so many requests on the KEXT side of things, that some get to the soconnect before the daemon has a chance to set up again and be ready to accept new connections. Any thoughts on how to over come this? Thanks, Matt On Feb 21, 2004, at 2:40 PM, Justin Walker wrote: On Saturday, February 21, 2004, at 01:30 PM, Matt Jaffa wrote: I think I have it working now, The KEXT disconnected from it before, but after 250 connections it still started that mess, Keep in mind that even though one end of a 'channel' closes it, the other end remains open until that end is closed. but now In the daemon I have it creating a socket then accepting and after it has done the communication, I close the the socket and it is working fine now. FWIW, I think that opening and closing a connection for each exchange may be overkill (or inefficient). You have to evaluate this based on the frequency of exchange, and the cost of the open/close operations. I'm happy you got it fixed. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | "Weaseling out of things is what | separates us from the animals. | Well, except the weasel." | - Homer J Simpson *-------------------------------------- *-------------------------------* _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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.

1 0

Re: IPC with Sockets
by Justin Walker 21 Feb '04

21 Feb '04

On Saturday, February 21, 2004, at 01:30 PM, Matt Jaffa wrote: I think I have it working now, The KEXT disconnected from it before, but after 250 connections it still started that mess, Keep in mind that even though one end of a 'channel' closes it, the other end remains open until that end is closed. but now In the daemon I have it creating a socket then accepting and after it has done the communication, I close the the socket and it is working fine now. FWIW, I think that opening and closing a connection for each exchange may be overkill (or inefficient). You have to evaluate this based on the frequency of exchange, and the cost of the open/close operations. I'm happy you got it fixed. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | "Weaseling out of things is what | separates us from the animals. | Well, except the weasel." | - Homer J Simpson *--------------------------------------*-------------------------------* _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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.

1 0

Re: IPC with Sockets
by Matt Jaffa 21 Feb '04

21 Feb '04

Thanks for responding Justin, I think I have it working now, The KEXT disconnected from it before, but after 250 connections it still started that mess, but now In the daemon I have it creating a socket then accepting and after it has done the communication, I close the the socket and it is working fine now. Matt On Feb 21, 2004, at 1:51 PM, Justin Walker wrote: On Saturday, February 21, 2004, at 07:18 AM, Matt Jaffa wrote: Hi, SO thanks to all those that have replied in the past and pointed me towards using Steven's book Vol. 2, that has helped a lot. Another problem has come up that I can't find addressed in Steven's book. I have a daemon running forever accepting connections and then receiving info and responding back to my KEXt all using the AF_UNIX sockets, This works great except when the daemon has received about 250 connections it starts throwing error 24 (EMFILE) too many files open, I know that a process's limit of this can be increased, but I would like a fix that doesn't require that, I want it where after the connection was accepted by the daemon and it receives and sends info, that it can close that connection, so as to prevent this error. Hmmm...it sounds as if you haven't completely figured out your communication scheme. First, if this is communication between one daemon and one KEXT, why keep opening connections? Can't you reuse the same one? Second, if it is important to have new connections, why can't one end or the other close when done? The last guy to send can cloes his end; and the last guy to receive can close the socket, at which point the whole connection goes away. Perhaps I don't understand enough of what you are trying to achieve. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Men are from Earth. | Women are from Earth. | Deal with it. *-------------------------------------- *-------------------------------* _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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.

1 0

Re: IPC with Sockets
by Justin Walker 21 Feb '04

21 Feb '04

On Saturday, February 21, 2004, at 07:18 AM, Matt Jaffa wrote: Hi, SO thanks to all those that have replied in the past and pointed me towards using Steven's book Vol. 2, that has helped a lot. Another problem has come up that I can't find addressed in Steven's book. I have a daemon running forever accepting connections and then receiving info and responding back to my KEXt all using the AF_UNIX sockets, This works great except when the daemon has received about 250 connections it starts throwing error 24 (EMFILE) too many files open, I know that a process's limit of this can be increased, but I would like a fix that doesn't require that, I want it where after the connection was accepted by the daemon and it receives and sends info, that it can close that connection, so as to prevent this error. Hmmm...it sounds as if you haven't completely figured out your communication scheme. First, if this is communication between one daemon and one KEXT, why keep opening connections? Can't you reuse the same one? Second, if it is important to have new connections, why can't one end or the other close when done? The last guy to send can cloes his end; and the last guy to receive can close the socket, at which point the whole connection goes away. Perhaps I don't understand enough of what you are trying to achieve. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Men are from Earth. | Women are from Earth. | Deal with it. *--------------------------------------*-------------------------------* _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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.

1 0

IPC with Sockets
by Matt Jaffa 21 Feb '04

21 Feb '04

Hi, SO thanks to all those that have replied in the past and pointed me towards using Steven's book Vol. 2, that has helped a lot. Another problem has come up that I can't find addressed in Steven's book. I have a daemon running forever accepting connections and then receiving info and responding back to my KEXt all using the AF_UNIX sockets, This works great except when the daemon has received about 250 connections it starts throwing error 24 (EMFILE) too many files open, I know that a process's limit of this can be increased, but I would like a fix that doesn't require that, I want it where after the connection was accepted by the daemon and it receives and sends info, that it can close that connection, so as to prevent this error. Any suggestions? Thanks, Matt _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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.

1 0

Re: Deadlock in My KEXT with NKE
by Mike Smith 18 Feb '04

18 Feb '04

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 | darwin-kernel(a)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.

1 0

Re: Deadlock in My KEXT with NKE
by Brian Bergstrand 17 Feb '04

17 Feb '04

-----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(a)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.

1 0

Help with my IPC
by Matt Jaffa 17 Feb '04

17 Feb '04

Hi, So I am trying to communicate between my NKE and Daemon, I have tried everything. I tried all different kinds of Sockets but I can't get the KEXT to connect with my listening socket(daemon) and send message and then receive, So I went back to my sysctlbyname way of doing it, but there are still problems with it cause it goes into Deadlock. Here is the code of the function that spins in a while loop till the daemon is done with its work. any suggestions? int vi_send2(struct socket *so, struct sockaddr **addr, struct uio **uio, struct mbuf **top, struct mbuf **control, int *flags, register struct kextcb *kp) { int funnel_state; funnel_state = thread_funnel_set(network_flock, TRUE); if(somo.the_value != NULL) { //int errordd = soconnect2(soed3, somo.the_value); //printf("This is the error from send2 error: %d\n", errordd); char thiscmd[MAXCOMLEN + 1]; struct proc * testing; //unsigned long length; testing = current_proc(); printf("This process is communicating: %d\n",testing->p_pid); //somo2.p_pid = testing->p_pid; //strncopy(thiscmd, testing->p_comm, MAXCOMLEN); sprintf(thiscmd, "%s", testing->p_comm); //copyinstr(testing->p_comm, thiscmd, MAXCOMLEN, &length); thiscmd[MAXCOMLEN] = '\0'; printf("This is the proccess name: %s\n",thiscmd); struct ip * ipHeader; ipHeader = mtod(*top,struct ip *); u_short port; struct tcphdr * header = NULL; header = (struct tcphdr *)&((int32_t *)ipHeader)[ipHeader->ip_hl]; port = header->th_dport; printf("IP TCP :- TCP attempt by PID(%d) to %s (port %d)\n ",testing->p_pid,inet_ntoa(ipHeader->ip_dst),port); printf("\nIP SRC : %s\n", inet_ntoa(ipHeader->ip_src)); printf("IP DEST: %s\n\n", inet_ntoa(ipHeader->ip_dst)); work_to_do = 1; //int stuff = 0; while(conditional_val == 0) { (void) tsleep((caddr_t) & so->so_timeo, PSOCK, "Testing", 2 * hz); printf("IP DEST: %s\n\n", inet_ntoa(ipHeader->ip_dst)); //sleep(1); } //sbunlock(&so->so_snd); //*top = NULL; conditional_val = 0; //return EACCES; work_to_do = 0; if(somo2.block == 1) { thread_funnel_set(network_flock, funnel_state); return EACCES; } } thread_funnel_set(network_flock, funnel_state); return 0; } conditional_val == to the var that controls the while loop, daemon will signal 1 when done with the work work_to_do == lets the daemon know to ask for the info from KEXT so it can process it. Since dameon is spinning in a loop until it detects work_to_do == 1; See any problems with this implementation. I know that when multiple things are going, and say a process is switched during the while loop where it sleeps, then it starts to go into deadlock. Thanks, Matt _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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.

1 0

Re: Changes to Disk Arbitration in Panther
by Ron Aldrich 17 Feb '04

17 Feb '04

On Feb 14, 2004, at 1:36 PM, Marek Kozubal wrote: > On Wed, 4 Feb 2004, Ron Aldrich wrote: > >> Folks, >> >> Does anyone know where to find documentation for the changes made to >> disk arbitration in panther? > > Look at the source code. Thats all there is. > >> I've finally gotten some time to look at updating our ReadDVD product >> for 10.3, and it seems like our filesystem isn't being recognized by >> the system at all, even though it appears to be installed identically >> to the other filesystems. > > DA was rewritten between 10.2 and 10.3. There is a new "almost public" > API now that you need to use. > >> (If anyone has suggestions for debugging it, I'm all ears - I've been >> away from it long enough to have forgotten most of my old tricks). > > In the file /etc/mach_init.d/diskarbitrationd.plist you can add > -d to the "Command" string to turn on debugging which ends up in like > /var/log/diskarbitration.log or some such. > > --- > Marek Kozubal > marek(a)portents.com > I enabled debugging in diskarbitrationd.plist, and after inserting a disk, I found the following in /var/log/diskarbitrationd.log 18:40:25 diskarbitrationd [90] -> diskarbitrationd [90] 18:40:25 probed disk, id = /dev/disk2, with SAI_udf, ongoing. 18:40:25 probed disk, id = /dev/disk2, with SAI_udf, failure. 18:40:25 probed disk, id = /dev/disk2, with udf, ongoing. 18:40:25 probed disk, id = /dev/disk2, with udf, success. 18:40:25 18:40:25 diskarbitrationd [90] -> SystemUIServer [333]:14339 18:40:25 dispatched callback, id = 907F45EC:00000000, kind = disk mount approval, disk = /dev/disk2. 18:40:25 dispatched callback queue. 18:40:25 18:40:25 SystemUIServer [333]:14339 -> diskarbitrationd [90] 18:40:25 dispatched response, id = 907F45EC:00000000, kind = disk mount approval, disk = /dev/disk2, approved. 18:40:25 18:40:25 diskarbitrationd [90] -> diskarbitrationd [90] 18:40:25 mounted disk, id = /dev/disk2, ongoing. 18:40:26 mounted disk, id = /dev/disk2, failure. 18:40:26 unable to mount /dev/disk2 (status code 0x00000001). This tells me that disk arbitration is finding my file system, but for some reason it fails when it tries to probe it. As far as I can tell, it never actually launches SAI_udf.util - for some reason it fails before it gets that far. It then continues on, and fails later, when Apple's UDF tries to mount the disc (the disc is formatted as UDF 2.01, so Apple's UDF won't touch it). I tried hard coding the full path to SAI_udf.util (/System/Library/Filesystems/SAI_udf.fs/SAI_udf.util) in my Info.plist, but that had no effect. I also tried changing my probe order value from 500 to 1500 (Apple's udf probe order value is 1000), but that just made it so that disk arbitration never even tried to probe SAI_udf. I tried searching around in what bit of the darwin sources I currently have available (xnu-517.3.7) for "probed disk" to find where the error message is being generated, but I can't find that string, and since Apple seems to have done their best to make it extremely difficult to check all of darwin out from CVS, I really don't want to have to load it project by project, just to search it. (Does anyone know a trick for checking all of darwin out at once? Or failing that, how to get a list of all of the module names?) Thanks, Ron Aldrich Software Architects, Inc. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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.

1 0

Re: Deadlock in My KEXT with NKE
by Matt Jaffa 15 Feb '04

15 Feb '04

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 _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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.

1 0