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@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@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.