Hello, On Sat, Aug 07, 2010 at 09:29:06PM -0400, Jon Smirl wrote: > >> You will lose access to > >> compressed packets on the normal interfaces (they will still be there > >> on the monitor interface). To get rid of it rmmod 6lowpan. To switch > >> to zigbee modprobe zigbee. > > > > No. This is totally unacceptable. One of the users of wpan device shan't > > My current code creates another interface like wpan, smac for 6lowpan. > The interface then chains into the wpan code. I figured that model > out by looking at the ax25/netrom/rose implementation. It should be > possible to poll the packets to both the lowpan and zigbee code. > > ax25 = wpan > netrom = 6lowpan > rose = zigbee > > It is not obvious how to hook 6lowpan into the stack. I have tried > about five different schemes so far. I'm linking into the mac802154 > module at the moment, we can split 6lowpan out later if needed.
I'd really prefer if the 6lowpan code is added to some more generic place from the beginning. It should be hookable into packet receive path by registering _rcv handler for necessary frames: struct packet_type *lwppkt = kzalloc(...); lwppkt->type = htons(ETH_P_IEEE802154); /* or NULL if you would really like to receive 802.15.4 data from all interfaces */ lwppkt->dev = wpan_dev_for_lwp; lwppkt->func = lowpan_rcv; /* receives parsed 802.15.4 frame */ dev_add_pack(lwppkt); You may need to adjust af_ieee802154 code if it will interfere (it should not, but I ain't sure) with 6lowpan code. Following this way you become completely undependant on other wpan code. Moreover we can then merge 6lowpan even before main mac802154 is ready. > > block other users. Moreover what about devices with several wpan > > interfaces, where some of them should be 6lowpan, some of them should be > > zigbee (BTW: kernel implementation of zigbee seems to be impossible due > > to licensing agreements under which ZigBee Alliance provides > > specifications). > > The current Zigbee is going to die in a few year. Zigbee over IP > should replace it. Will luck 6lowpan/RPL/COAP will beat them too it. RPL = ROLL? COAP = ? > > I'd like to see the whole Zigbee stack die because of their refusal to > cooperate with the GPL. Their board was asked to cooperate and they > refused to make the needed licensing adjustments. Yeah. I don't mind if they don't want to cooperate with GPL/OSS community. Nobody is forced to do that. But not answering to license clarification requests is really not the way to go. Bluetooth had (IIRC) the same problems once, but they have resolved them and now we have Bluetooth stack. Talking about "products" in _specification_ license is completely nosense (IMO). -- With best wishes Dmitry ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Linux-zigbee-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
