2009/6/5 Marcel Holtmann <marcel@xxxxxxxxxxxx>: > Hi Dmitry, > >> >> Add MAINTAINERS entry and a small text describing our stack interfaces, >> >> how to hook the drivers, etc. >> >> >> >> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@xxxxxxxxx> >> >> Signed-off-by: Sergey Lapin <slapin@xxxxxxxxxxx> >> >> --- >> >> Documentation/networking/ieee802154.txt | 76 +++++++++++++++++++++++++++++++ >> >> MAINTAINERS | 12 +++++ >> >> 2 files changed, 88 insertions(+), 0 deletions(-) >> >> create mode 100644 Documentation/networking/ieee802154.txt >> >> >> >> diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt >> >> new file mode 100644 >> >> index 0000000..a0280ad >> >> --- /dev/null >> >> +++ b/Documentation/networking/ieee802154.txt >> >> @@ -0,0 +1,76 @@ >> >> + >> >> + Linux IEEE 802.15.4 implementation >> >> + >> >> + >> >> +Introduction >> >> +============ >> >> + >> >> +The Linux-ZigBee project goal is to provide complete implementation >> >> +of IEEE 802.15.4 / ZigBee / 6LoWPAN protocols. IEEE 802.15.4 is a stack >> >> +of protocols for organizing Low-Rate Wireless Personal Area Networks. >> >> + >> >> +Currently only IEEE 802.15.4 layer is implemented. We have choosen >> >> +to use plain Berkeley socket API, the generic Linux networking stack >> >> +to transfer IEEE 802.15.4 messages and a special protocol over genetlink >> >> +for configuration/management >> >> + >> >> + >> >> +Socket API >> >> +========== >> >> + >> >> +int sd = socket(PF_IEEE802154, SOCK_DGRAM, 0); >> >> +..... >> >> + >> >> +The address family, socket addresses etc. are defined in the >> >> +include/net/ieee802154/af_ieee802154.h header or in the special header >> >> +in our userspace package (see either linux-zigbee sourceforge download page >> >> +or git tree at git://linux-zigbee.git.sourceforge.net/gitroot/linux-zigbee). >> >> + >> >> +One can use SOCK_RAW for passing raw data towards device xmit function. YMMV. >> >> + >> >> + >> >> +MLME - MAC Level Management >> >> +============================ >> >> + >> >> +Most of IEEE 802.15.4 MLME interfaces are directly mapped on netlink commands. >> >> +See the include/net/ieee802154/nl802154.h header. Our userspace tools package >> >> +(see above) provides CLI configuration utility for radio interfaces and simple >> >> +coordinator for IEEE 802.15.4 networks as an example users of MLME protocol. >> >> + >> >> + >> >> +Kernel side >> >> +============= >> >> + >> >> +Like with WiFi, there are several types of devices implementing IEEE 802.15.4. >> >> +1) 'HardMAC'. The MAC layer is implemented in the device itself, the device >> >> + exports MLME and data API. >> >> +2) 'SoftMAC' or just radio. These types of devices are just radio transceivers >> >> + possibly with some kinds of acceleration like automatic CRC computation and >> >> + comparation, automagic ACK handling, address matching, etc. >> >> + >> >> +Those types of devices require different approach to be hooked into Linux kernel. >> >> + >> >> + >> >> +HardMAC >> >> +======= >> >> + >> >> +See the header include/net/ieee802154/netdevice.h. You have to implement Linux >> >> +net_device, with .type = ARPHRD_IEEE802154. Data is exchanged with socket family >> >> +code via plain sk_buffs. The control block of sk_buffs will contain additional >> >> +info as described in the struct ieee802154_mac_cb. >> > >> > are you sending IP packets over this ARPHRD_IEEE802154 network devices >> > or are you just abusing it as a control interface. If it is the later >> > then can we please stop doing this. I really dislike these irda0, >> > wmaster0 and alike stuff. If you can't configure it as real IP device, >> > you should not use struct net_device at all from my point of view. For >> > all your control details you have netlink so no need for an extra device >> > here unless it can actually talk IP (or similar like IPX etc.). >> >> Hmm. Once I've thought about it, as net_device seemed a Really Big Thing to me >> to be used for our stack. However from the beginning we wanted to use plain BSD >> sockets API, we wanted to use sk_buffs (of course) for the whole >> message interface. >> And when prototyping lowpan_device, I ended duplicating lots of net_device >> functionality on my own. >> Either we have to develop some lightweight "net_device" abstracted from IP & Ko, >> but containing sk_buff queues, header ops, etc, or end up with functionality >> duplication and hacks like in bluetooth (where skb->dev is used to store hci_dev >> instead of net_device). > > that skb->dev pointer is typed as net_device is just a cosmetic detail > from my point of view. And having Bluetooth use it as hci_dev is not > actually a hack. We just can't send Bluetooth HCI skb directly to the IP > layer, but we also don't do that ;) > >> Hmm. AX.25, AppleTalk, CAN, DecNet, most of other procotols sitting inside >> Linux kernel do use net_device structure, why should we differ? > > Don't know about CAN since I never looked deep enough into it. However > for the other, they do transport some sort of networking packets over > it. So my point is as long as I can use ifconfig of ip to set an address > on these interfaces and route them it makes sense to. Just to reuse > net_device because it is convenient for a control interface sounds wrong > to me. The IrDA stuff is one big example of this. Hmm. Let's make things clear: do you request for ip/ifconfig to be working upon a net_device or do you request that network packets are transmitted over the net_device? >> Moreover, once we implement 6lowpan support (an encapsulation for IPv6 frames >> into IEEE 802.15.4 ones) it will be possible to send IPv6 frames directly over >> IEEE 802.15.4. > > So using the socket interfaces has nothing do with the net_device you > are creating. So that argument doesn't work for me. Even mac80211 > nowadays uses a proper hardware abstraction (ieee80211_hw and > ieee80211_ops) and you should do the same. We have more or less the same abstraction for the simple radios (if you'd like, please check the serie at the branch for-review-v2, or the serie that was posted several days ago. Basically simple radio provide interface for packet rx/tx, energy detection, etc. Then mac802154 (mac80211 analogy) comes into play: all radio packets, queue processing, etc. are guided by master interface, which multiplexes packets from/to one or several ARPHRD_IEEE802154 interfaces. Those interfaces then decode if the packet is beacon, command or data frame, passes data frames to socket family, calls netlink callbacks for commands, etc. While I understand that master interface can be dropped/replaced by non-net_device thing, I think that logical interfaces should be provided via net_device. Please correct me if I'm wrong here. For HardMAC (that part that is presented in this patchseri) we've cut this scheme directly at ARPHRD_IEEE802154 device. The device driver on it's own sends/ receives data frames via hardware and calls MLME callbacks where appropriate. > Once you have actually implemented 6lowpan then these are the ones that > should use net_device and show up within ifconfig. -- With best wishes Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
