Re: IOKit Network Subclass Guidance
Re: IOKit Network Subclass Guidance
- Subject: Re: IOKit Network Subclass Guidance
- From: Michael Cashwell <email@hidden>
- Date: Thu, 12 Jun 2003 09:35:19 -0400
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 | 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.
_______________________________________________
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.