June 2003 - Darwin-kernel - lists.apple.com

DSI wrapper & AFP - tickles
by andre＠hugesystems.com 12 Jun '03

12 Jun '03

I was just curious if there was open source available for the DSI (data stream interface ?) wrapper around AFP. Thanks for any and all help. Andre N. Karobkoff Software Engineer/Analyst H U G E Systems, Inc. 30414 Agoura Road, Suite 212 Agoura Hills, CA 91301 (818) 991-1188 EXT. 15 www.hugesystems.com _______________________________________________ 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: IOKit Network Subclass Guidance
by Michael Cashwell 12 Jun '03

12 Jun '03

Thanks for the info Justin! It seems clear from the responses that IOEthernetController is the right parent class and that I will publish (not subclass) a IOEthernetInterface instance. (Thanks Joe!) Since I'm just getting my feet wet with ATM I'd like to discuss the LANE v. MPOA issue a bit more. What I'm writing here is my admittedly green and limited understanding. Aside from some basic signaling and "call" setup & tear down (you can really see the basis in telephony with ATM!), I'm pretty sure that ALL user-level (i.e. application) data must be connection oriented. Even plain LANE maps ATM circuits to 802.mumble MAC addresses. (Broadcasts and multicasts use a proxy but those too eventually go over connection-oriented ATM circuits.) By caching these circuits hosts can send what appear to be connectionless datagrams. Literally, each entry in a host's ARP table for a LANE interface maps to an ATM circuit. (The chips support thousands of simultaneous circuits which are inherently bidirectional.) While the name MPOA (Multiprotocol over ATM) seems a misnomer, from what I've read, it's just an add-on to LANE that allows a LANE Client to "notice" that a significant amount of traffic for one destination host is flowing in or out of one's ELAN (which is LANE's equivalent of a local subnet in Ethernet). It can then query the local ATM gateway and setup a virtual circuit directly with the remote host (or whatever the farthest ATM node is). This takes the traffic off the local ELAN's gateway and is like being able to add a distant host to one's ARP table. (This pushes routing down to the cell level where ATM does it in dedicated (fast!) switch fabric rather than in CPU-based routers that need a lot of protocol knowledge. This is one of ATM's features.) Once such an MPOA circuit is up it behaves just like the local ones under LANE. So I think the connection orientation applies to both LANE and MPOA equally. Of course, I could just be all wet. I guess I'll find out soon enough... Any further insights or ideas are, of course, welcome. Thanks, Mike On Wednesday, June 11, 2003, at 05:23 PM, Justin C. Walker wrote: On Wednesday, June 11, 2003, at 08:03 AM, Joe Liu wrote: Hi Mike, On Tuesday, June 10, 2003, at 11:54 AM, Michael Cashwell wrote: [snip] I've been tasked with developing an IOKit driver for an ATM PCI card. I've worked on NKEs before and have done some preliminary development on another Ethernet driver that never got very far. My basic question at present is where in IOKit to subclass. If I were developing a full blown ATM driver (with support for ATM routing and all manner of other ATM-specific interfaces and protocols) I expect I'd want to subclass IONetworkController. But this project is more limited. It only needs to be a LANE (LAN Emulation) Client and perhaps someday to support MPOA (Multiprotocol over ATM; essentially adding a next-hop resolution protocol that allows for direct ATM connections across routers). The key element here is that the OS's view of a LANE Client ATM interface is exactly the same as an 802.x-based Ethernet interface: 6-octet MAC addresses, roughly 1500-octet MTU, unicast, multicast, and broadcast support, and so forth. This makes me think I should subclass IOEthernetController. There will be a private interface (via a specialized ATM-aware User Client I expect) between my driver and a userland daemon which runs a LANE ARP state machine. But the rest of the OS would just see a published nub that looks, smells and tastes like a normal Ethernet interface. At least, that's what I'm thinking presently. Does this seem like the right approach? And if so, which superclass would be better? My hunch is IOEthernetController but I'm concerned about subclassing what is already a concrete class. If I have to fight it at every step then its parent is probably a better choice. For example, I want the interface name(s) (like those listed by ifconfig) to be "lec#" (standing for LANE Client) not "en#". I'm not familiar with ATM but based on your description, IOEthernet* sounds like the proper level to subclass from. Then extend it by overriding its implementation. For instance, to change the "en" name, subclass IOEthernetInterface and implement getNamePrefix(). Why subclass IOEthernetInterface? See below. I'm not on intimate terms with the IOKit world, but: - for LANE, I agree that IOEthernet* is a reasonable approach (since LANE is emulating an ethernet (a LAN, actually), after all). - for MPOA, I'm not so sure. My concern is that ATM presents a connection- oriented view of the world (ignoring the LANE cruft), and IOEthernet* is datagram-oriented ('connectionless' - ick). I don't think that using IOEthernet* for MPOA is a good approach (square pegs/round hole). It may be that you have to break new IOKit ground to support MPOA or 'native ATM', since a connection-oriented networking layer is somewhat foreign to both sockets and IOKit. There is an extension of the sockets API to handle connection-oriented networking (at layers below the transport layer); I think that work was done through X/Open and The Open Group [wherever they are now], and it might be worth doing a little googling to find out what that work looks like. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | It's not whether you win or lose... | It's whether *I* win or lose. *-------------------------------------- *-------------------------------* _______________________________________________ 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: IOKit Network Subclass Guidance
by Justin C. Walker 11 Jun '03

11 Jun '03

On Wednesday, June 11, 2003, at 08:03 AM, Joe Liu wrote: Hi Mike, On Tuesday, June 10, 2003, at 11:54 AM, Michael Cashwell wrote: [snip] I've been tasked with developing an IOKit driver for an ATM PCI card. I've worked on NKEs before and have done some preliminary development on another Ethernet driver that never got very far. My basic question at present is where in IOKit to subclass. If I were developing a full blown ATM driver (with support for ATM routing and all manner of other ATM-specific interfaces and protocols) I expect I'd want to subclass IONetworkController. But this project is more limited. It only needs to be a LANE (LAN Emulation) Client and perhaps someday to support MPOA (Multiprotocol over ATM; essentially adding a next-hop resolution protocol that allows for direct ATM connections across routers). The key element here is that the OS's view of a LANE Client ATM interface is exactly the same as an 802.x-based Ethernet interface: 6-octet MAC addresses, roughly 1500-octet MTU, unicast, multicast, and broadcast support, and so forth. This makes me think I should subclass IOEthernetController. There will be a private interface (via a specialized ATM-aware User Client I expect) between my driver and a userland daemon which runs a LANE ARP state machine. But the rest of the OS would just see a published nub that looks, smells and tastes like a normal Ethernet interface. At least, that's what I'm thinking presently. Does this seem like the right approach? And if so, which superclass would be better? My hunch is IOEthernetController but I'm concerned about subclassing what is already a concrete class. If I have to fight it at every step then its parent is probably a better choice. For example, I want the interface name(s) (like those listed by ifconfig) to be "lec#" (standing for LANE Client) not "en#". I'm not familiar with ATM but based on your description, IOEthernet* sounds like the proper level to subclass from. Then extend it by overriding its implementation. For instance, to change the "en" name, subclass IOEthernetInterface and implement getNamePrefix(). Why subclass IOEthernetInterface? See below. I'm not on intimate terms with the IOKit world, but: - for LANE, I agree that IOEthernet* is a reasonable approach (since LANE is emulating an ethernet (a LAN, actually), after all). - for MPOA, I'm not so sure. My concern is that ATM presents a connection- oriented view of the world (ignoring the LANE cruft), and IOEthernet* is datagram-oriented ('connectionless' - ick). I don't think that using IOEthernet* for MPOA is a good approach (square pegs/round hole). It may be that you have to break new IOKit ground to support MPOA or 'native ATM', since a connection-oriented networking layer is somewhat foreign to both sockets and IOKit. There is an extension of the sockets API to handle connection-oriented networking (at layers below the transport layer); I think that work was done through X/Open and The Open Group [wherever they are now], and it might be worth doing a little googling to find out what that work looks like. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | It's not whether you win or lose... | It's whether *I* win or lose. *--------------------------------------*-------------------------------* _______________________________________________ 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: Current Directory of a Process
by Robert Sandilands 11 Jun '03

11 Jun '03

Initially I want to create a log for auditing purposes of all files opened/created/renamed/deleted and all programs executed. All of these things can be done with relative pathnames which is why I need the ability to get the current working directory of a process. Later on I would like to be able to redirect or disallow any of these actions. I'm not worried about disappearing paths or of the many path's to a file, I monitor delete attempts and I need any one path to log. I am open to any suggestions. Robert Sandilands On Wednesday, June 11, 2003, at 11:49 AM, Jim Magee wrote: On Wednesday, June 11, 2003, at 11:03 AM, Robert Sandilands wrote: It's the same issue trying to translate any other open file (directory) to a path. You can't! At least not reliably. For one thing, there might not be a path anymore (the last link to the file/directory was deleted while you had an open reference to it). This is perfectly legal in BSD. For another, with hard-links, there may be MANY paths to the open file (not an issue with directories because of the inability to hard-link to a directory). Not all of which your application can use (because of permissions on intervening directories). Again, we have to ask "what are you trying to accomplish?" It sounds like you may need to re-factor which parts of your application belong in user space and which parts belong in the kernel. --------------------------------------------------------------------- #include http://robert.rsa3.com/disclaimer.html _______________________________________________ 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: Current Directory of a Process
by Jim Magee 11 Jun '03

11 Jun '03

On Wednesday, June 11, 2003, at 11:03 AM, Robert Sandilands wrote: I can get the vnode pointing to the current directory, and that is good... Sort of. I need to be able to translate this vnode to a path name to be used in user space. I have poured through the kernel and not found a way to do that. In desperation I downloaded the code for Libc and looked at the getcwd code. Horror! If you want to spend some sleepless nights having nightmares look at Libc/gen/getcwd.c. Obviously that type of solution is not practical for the kernel. Any ideas how to translate a vnode to a path? It's the same issue trying to translate any other open file (directory) to a path. You can't! At least not reliably. For one thing, there might not be a path anymore (the last link to the file/directory was deleted while you had an open reference to it). This is perfectly legal in BSD. For another, with hard-links, there may be MANY paths to the open file (not an issue with directories because of the inability to hard-link to a directory). Not all of which your application can use (because of permissions on intervening directories). Again, we have to ask "what are you trying to accomplish?" It sounds like you may need to re-factor which parts of your application belong in user space and which parts belong in the kernel. --Jim _______________________________________________ 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: Current Directory of a Process
by Robert Sandilands 11 Jun '03

11 Jun '03

I can get the vnode pointing to the current directory, and that is good... Sort of. I need to be able to translate this vnode to a path name to be used in user space. I have poured through the kernel and not found a way to do that. In desperation I downloaded the code for Libc and looked at the getcwd code. Horror! If you want to spend some sleepless nights having nightmares look at Libc/gen/getcwd.c. Obviously that type of solution is not practical for the kernel. Any ideas how to translate a vnode to a path? Or any other ideas how to get the current directory? Thanks Robert Sandilands On Monday, June 9, 2003, at 06:33 PM, Justin C. Walker wrote: On Monday, June 9, 2003, at 02:52 PM, Robert Sandilands wrote: I have a struct proc * inside a sysent[xxx] call and from there want to get the current working directory of the process that initiated the action. I have looked through the kernel and the mailing list archives and not found any obvious pointers. Does anybody have any ideas? You can look at xnu/bsd/vfs/vfs_syscalls:chdir() to see how the various structures are stitched together. Is this what you are looking for? Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Some people have a mental | horizon of radius zero, and | call it their point of view. | -- David Hilbert *-------------------------------------- *-------------------------------* _______________________________________________ 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. --------------------------------------------------------------------- #include http://robert.rsa3.com/disclaimer.html _______________________________________________ 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: IOKit Network Subclass Guidance
by Joe Liu 11 Jun '03

11 Jun '03

Hi Mike, On Tuesday, June 10, 2003, at 11:54 AM, Michael Cashwell wrote: Greetings all, I've been tasked with developing an IOKit driver for an ATM PCI card. I've worked on NKEs before and have done some preliminary development on another Ethernet driver that never got very far. My basic question at present is where in IOKit to subclass. If I were developing a full blown ATM driver (with support for ATM routing and all manner of other ATM-specific interfaces and protocols) I expect I'd want to subclass IONetworkController. But this project is more limited. It only needs to be a LANE (LAN Emulation) Client and perhaps someday to support MPOA (Multiprotocol over ATM; essentially adding a next-hop resolution protocol that allows for direct ATM connections across routers). The key element here is that the OS's view of a LANE Client ATM interface is exactly the same as an 802.x-based Ethernet interface: 6-octet MAC addresses, roughly 1500-octet MTU, unicast, multicast, and broadcast support, and so forth. This makes me think I should subclass IOEthernetController. There will be a private interface (via a specialized ATM-aware User Client I expect) between my driver and a userland daemon which runs a LANE ARP state machine. But the rest of the OS would just see a published nub that looks, smells and tastes like a normal Ethernet interface. At least, that's what I'm thinking presently. Does this seem like the right approach? And if so, which superclass would be better? My hunch is IOEthernetController but I'm concerned about subclassing what is already a concrete class. If I have to fight it at every step then its parent is probably a better choice. For example, I want the interface name(s) (like those listed by ifconfig) to be "lec#" (standing for LANE Client) not "en#". I'm not familiar with ATM but based on your description, IOEthernet* sounds like the proper level to subclass from. Then extend it by overriding its implementation. For instance, to change the "en" name, subclass IOEthernetInterface and implement getNamePrefix(). Why subclass IOEthernetInterface? See below. Lastly, how might IONetworkInterface and IOEthernetInterface figure into this? Do these classes abstract things like topology (bus, point to point, ring) and medium (UTP, fiber) or is it more than that? Its quite simple. The interface is the "nub" that is published by a controller driver. The interface class encapsulates an ifnet structure and manages its state. By attaching itself to DLIL, it exposes its services to the networking layers. But the interface is not a complete interface driver, and must rely on its provider to access the hardware and do the work. This split means that the controller has the hardware dependent bits, while the code that is hardware independent and common among all drivers of the same network type lives in the interface. Most drivers only subclass the controller, but nothing prevents a driver from defining an interface subclass. Being an interface, it does not deal with network topology issues, but it does handle network interface ioctls, including SIOCSIFMEDIA and SIOCGIFMEDIA used to report the media capabilities and to change the medium type. There is an IONetworkMedium class that abstracts a network medium. -Joe Thanks for any input. -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: Socket NKE performance
by Stéphane Sudre 11 Jun '03

11 Jun '03

On jeudi, juin 5, 2003, at 19:35 Europe/Paris, Joshua Graessley wrote: On Thursday, June 5, 2003, at 7:33, Stiphane Sudre wrote: I'm testing what kind of performance I can get from a Socket NKE communication from a Kernel Extension to a user land application. I set the recv_space of the socket to be 224 KB in the Kernel In the application, I'm using a CFSocket to read the data when available. To communicate with the application I'm sbappending 32 Bytes data using the same kind of code that the NKE tcpdumper sample code. My unrealistic dream is to reach a peak of 1 MB/s. But 300 KB/s would already be fair. >From the test I'm making, the performance can just reach 25 KB/s. Is this not a bit weak compared to what should be expected? Is there a reason you're only writing 32 bytes at a time? Are you calling sorwakeup after each time that you write 32 bytes? It looks like that sending more data at a time is leading to better performance. This leads to a somewhat stranger but faster behavior. Instead of having: Data sent -> Data sent -> Data sent -> ... it's now: Data sent -> Data not sent -> 2 Data sent -> Data sent -> .... Thanks for the various answers which leads me to find this solution. _______________________________________________ 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: Current Process
by Sam Vaughan 11 Jun '03

11 Jun '03

Hi Joey, The kernel header file sys/proc.h might have what you need: extern struct proc *initproc, *kernproc; try passing kernproc to the open call. Sam On Wednesday, Jun 11, 2003, at 15:00 Australia/Melbourne, darwin-kernel-request(a)lists.apple.com wrote: How can I get the current process from inside a kernel extension? I've tried calling currentProcess(), but when that is included, the KEXT won't load becuase of unresolved symbols. _______________________________________________ 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: getting process info for a kext
by Joey Echeverria 11 Jun '03

11 Jun '03

I'm also trying to use a function in the Kernel.framework headers, namely current_proc() in sys/vm.h -Joey On Tuesday, June 10, 2003, at 07:49 PM, Garth Cummings wrote: Hi all, Since this flavor of question has been cropping up lately, it may be time to reiterate a point about kernel programming interfaces. If a function is not in Kernel.framework/Headers/, you can't use it in a kernel extension. And, if a function is defined for kernel use only, you can't use it in user space. Now back to our regular scheduled email. --gc On Tuesday, June 10, 2003, at 01:33 PM, Chris Silverberg wrote: Hi folks I have an existing kext that needs to be modified slightly to look at process information. The process information I need is performed elsewhere by calling 'sysctl' ala: mib[0] = CTL_KERN; mib[1] = KERN_PROC; mib[2] = KERN_PROC_ALL; error = sysctl(mib, 3, procInfo, &buffersize, NULL, NULL); This code works fine in the user land application, but now I want to do the same in the kext. It doesn't appear that I can directly call 'sysctl' from a kext, so can anyone help me determine the proper way of retrieving this information? Advice is greatly appreciated. thanks, Chris _______________________________________________ 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