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