Re: IOKit Network Subclass Guidance
Re: IOKit Network Subclass Guidance
- Subject: Re: IOKit Network Subclass Guidance
- From: "Justin C. Walker" <email@hidden>
- Date: Wed, 11 Jun 2003 14:23:31 -0700
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 | 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.