Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IOKit Network Subclass Guidance

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.
References: 
 >Re: IOKit Network Subclass Guidance (From: Joe Liu <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.