Re: IOKit Network Subclass Guidance
Re: IOKit Network Subclass Guidance
- Subject: Re: IOKit Network Subclass Guidance
- From: Joe Liu <email@hidden>
- Date: Wed, 11 Jun 2003 08:03:36 -0700
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 | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.