Hello, On Fri, Mar 2, 2012 at 1:35 PM, Prajosh Premdas <premdas.praj...@gmail.com> wrote: > Hi All > > I have been using the code and have been adding functionality for the mac > stack. I need certain inputs and have some doubts on the current code.
I'm sorry but your suggestions make nearly no sense. The current design is targeted different applications and different types of interfaces which can be bound to each radio. > > I have listed out my doubts below > > 1. The network device is currently registered / created using the add_iface > method, I would suggest to do the same during the driver probe (e.g. > spi_probe function in radios over spi bus). Problem seen is, more than one > nic devices or mac instance can be registered on a single radio and all of > the can be controlled using different user space application. In affect more > than one user space application can set parameters like channel or even > invoke scan association commands on a single radio. This > will definitely leads to to races. NO. The idea (as it is currently handled) is to be not so 802.15.4 centric on those radios. In reality one doesn't have to have IEEE 802.15.4 interface on WPAN PHY at all! E.g. I can use WPAN PHY radios with simple mac (SMAC) which meets my goals perfectly. I don't need 802.15.4 MAC code on that PHY. Or one can have two radios (PHYs) - one acting as 802.15.4 MAC, one acting as passive (or active) monitor interface. > > 2. RX path: All the command frames received are pushed to a common function > ieee802154_rx_irqsafe and finally to mac802154_monitors_rx. Suppose if i > have 2 radios one on Sub Ghz and another on 2.4Ghz both have the same PAN id > and both are coordinators (Suppose my device is a gateway cum coordinators > for 2 PANs) then the packets(mac commands) from both radios will be received > will be both user space netlink based applications(you have a cross talk). > If we map each of the radio to a network interface as described above it can > be handled. First, as I said, radio can not (and should not) be mapped to the network interface. Second. monitors_rx handle only monitoring interfaces on a radio. There are other types of interfaces and respective receive functions. Third. Netlink interface consists (currently) of two layers. One is more or less related to PHY handling (such as allocating/deallocating interfaces, providing page/channel information used by radio). Those notifications/commands use PHY ID to select corresponding WPAN PHY instance. Other type of commands are related to IEEE 802.15.4 PHY interface. They are specific to IEEE 802.15.4 network devices (be it softmac or hardmac). They use device id to communicate about particular device in question. Hope this makes things and design clear. It might make more sense to compare whole LoWPAN subsystem with WiFi subsystem. The main difference is that for mac802.11 devices we have sane default - most users would like a simple ethernet device (other types are mesh, AP, monitor, maybe more). For LoWPAN we don't have such sane default. LoWPAN != IEEE 802.15.4, so we don't want to enforce users to have that interface by default. -- With best wishes Dmitry ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
