Sorry missed the group
---------- Forwarded message ---------- From: Prajosh Premdas <premdas.praj...@gmail.com> Date: Fri, Mar 2, 2012 at 4:31 PM Subject: Re: [Linux-zigbee-devel] register net device during probe rather that add_iface To: Dmitry Eremin-Solenikov <dbarysh...@gmail.com> On Fri, Mar 2, 2012 at 3:26 PM, Dmitry Eremin-Solenikov <dbarysh...@gmail.com> wrote: > > 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 had an understanding that this project is meant for Linux to have a 802.15.4 mac stack and my suggestions were based on the same. I want to add 802.15.4 mac stack in Linux as per the IEEE 802.15.4 specification-2006 so where will it fit? > > > > > 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 -- Regards, Prajosh Premdas -- Regards, Prajosh Premdas ------------------------------------------------------------------------------ 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
