On 8/4/10, Jon Smirl <[email protected]> wrote: > On Tue, Aug 3, 2010 at 6:13 PM, Dmitry Eremin-Solenikov > <[email protected]> wrote: >> Hello, >> >> On 8/3/10, Jon Smirl <[email protected]> wrote: >>> On Sun, Aug 1, 2010 at 8:54 PM, Jon Smirl <[email protected]> wrote: >>>> This is a first pass, do you want to touch up the wpan ones? >>>> >>>> Signed-off-by: Jon Smirl <[email protected]> >>> >>> Are these MAC renames ok? If so can you apply the patch to your repo. >> >> The patch look sane. I've just had no time for it (yet). >> >>> Then we can do another round with more reorganization. For example, >>> should the MAC layer netlink commands move over into the mac module? >> >> No. MAC-level netlink command sit right in their place - as they are >> the interface >> for coordinator to generic IEEE 802.15.4 devices, not only softmac ones. > > I'm trying to figure out where to insert 6lowpan support but I'm
6lowpan should be just a listener for all 802.15.4 frames. We have not had come with any interface (other than BSD sockets). You can either implement some custom in-kernel skb interchange mechanism (but keep in mind also other possible users, like ZigBee, ZigBee RF4CE, WirelessHART, MiWi, etc.) or just use in-kernel socket interface (which is used e.g. by nfs-kernel-server, IIRC). > having trouble getting my head around the organization of the code. Maybe I should write some extended 'Design' documentation. Anyway I'll have to prepare that as a part of LinuxKongress talk. Basically: * There is a generic layer called af_ieee802154. It's just a BSD socket interface for 802.15.4 networks. * There is a generic layer called wpan-phy. It's just a common interface for the 802.15.4-PHY kind of radios (maybe it can be extended to support more modes, e.g. high-rate modes provided by atmel, chipcon chips). * Each 802.15.4 interface is presented in the system as a netdev with several special properties (ARPHRD_IEEE802154, ETH_P_IEEE802154, management ops at ml_priv, etc.). Each wpan-phy can be associated with any number (0..inf) of 802.15.4 netdevs. Each 802.15.4 netdev is associated with one phy. * There is a generic layer called nl802154. It's used for managing PHYs, PHY->netdev relationship, and managing WPAN netdevs (MLME). * 802.15.4 devices can implement either a dumb radio (like directly attached mc13192/mc13202), radio with several acceleration functions (at86rf231, cc2420?, etc.), or full internal implementation of 802.15.4 standard (e.g. dongles for Philips universal remote controllers), called hardmac. * While hardmac devices can be used with very small software wrapper, softmac (just radios) require software MAC functionality. mac802154 is a library providing this functionality in software. You can compare that to wifi stack: wifi cards implement both wifi phy objects and wifi configuration interfaces (cfg80211, nl80211), look at net/wireless. SoftMAC wifi cards require software component implementing MAC functionality (mac80211: net/mac80211), which plugs between 802.2 netdevs and dump (more or less) devies. On top of that there is small addition for 802.15.4 devices: most of the radios can also implement several other protocols (with raw capture/injection being implemented as just one of them). Currently we have following protocols supported by nl802154 and implemented in mac802154: monitor (raw capture/inj. + 2 byte FCS at the end), WPAN (802.15.4), SMAC (Freescale Simple MAC: 2-byte fixed header + 2 byte FCS). > > Should the hardware device support code in mac802154 be moved in > drivers/ieee802154 as a library? main.c and wpan.c Device support > code normally lives in the drivers tree. No and no. Again, please compare to 802.11 stack. > And then drivers/802154 moved to drivers/net/802154? Maybe. drivers/ieee802154 -> drivers/net/lrwpan seems logical. > After you do that the MAC code could be merged with net/ieee802154 or > put in a subdir /net/ieee802154/mac NO!!!! > We could have a subdir for each protocol - raw, mac, 6lowpan. 6lowpan should live on top of generic interfaces like nl802154/AF_IEEE802154/etc. It should not be tied to mac802154 in any kind. > I also can't figure out if mac/6lowpan can be demand loaded on packet > reception. mac802154 is required for software radios, so it will be loaded. Automatic loading of protocols living on top of 802.15.4 isn't possible, as 802.15.4 frames contain no 'protocol' field. Each handler should receive all frames and throw away unsupported ones. -- With best wishes Dmitry ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ Linux-zigbee-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
