Hello, Please don't top-post on the ML, it is considered a bad taste and bad etiquette.
On Sat, Mar 3, 2012 at 9:20 AM, Prajosh Premdas <premdas.praj...@gmail.com> wrote: > Hi All & Dmitry > > Now i see your point there and understand the design better. But i > have a few more doubts. Yes, not all configurations are logically possible. See below. > > Case #1: synchronous mlme commands(mlme_reset, mlme_get, mlme_set) > 2.code flow: I am running 2 configuration application one on each of > the net device interface and i set channel 11 for wsn0 and channel 15 > for wsn1. Now the radio sets the channel which has been set the last. > same is the case for any pib. Hmm. Do you talk about PIB or MIB? We did not implement PIB API (especially setting ones) on purpose. They should be handled by MLME. While we have LIST_PHY wich can return current page/channel, but I don't think there is real profit implementing full PIB/PHY controls. Consider e.g. channel hopping schemes (802.15.4e). Or schemes where hardware supports switching between different channels during idle windows. One should not control PIB directly. > > It is ok to have one monitor and another device kind of wsn interfaces. > > This flow i dont think is right. I think i have missed a major part in > your design. How do i stop multiple IEEE802154_DEV_WPAN type of > interfaces? There is no real stop hook right now. There should be one. But again it cannot be as simple, as "no two wpan devices". Consider retranslator example. For now the user is on his own in creating illogical combinations. > I hope you understood this problem. > > Once this is fixed i will discuss on the case#2 mlme functions like > association > > On Sat, Mar 3, 2012 at 2:48 AM, Dmitry Eremin-Solenikov > <dbarysh...@gmail.com> wrote: >> On Fri, Mar 2, 2012 at 3:52 PM, Felix Varghese <felixv1...@gmail.com> wrote: >>> Guys, I'd like to join the foray too :) >>> >>>> 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. >>> Ability to bind different types of interfaces to the same radio is >>> desirable. However, is there any scenario where multiple interfaces >>> would be simultaneously bound to the same radio at the same time? Or >>> did I misunderstand the purpose of storing a list of slaves in >>> mac802154_priv? Also, wouldn't this cause some confusion as to which >>> specific interface should handle packets received over a particular >>> radio? >> >> Yes. I want to have ability to bind monitor together with _any_ other >> interface. >> We do not have that implemented, but most probably being a retransmitter >> (coordinator in one segment and a child node in another) would require two >> interfaces bound to single node. I like the ability to control SMAC and >> 802.15.4 >> from single radio. Or another sample - participating in two different >> 802.15.4 >> networks at the same time. This reqires two subinterfaces. So, this should >> stay as it is, unless I see strong arguments to do it another way. >> >> And no, this won't cause any confusion: all interfaces bound to radio >> receive all >> packets (by design). It is a part of the interface to understand if it >> should receive >> this packet and handle it accordingly (drop). Consider two PANs on single >> radio. >> Each subinterface will receive all packets and drop all packets which belong >> to >> other PAN. >> >>> >>>> 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. >>> Doesn't IEEE802.15.4 qualify as a sane default? Even if it doesn't, >>> and we require the user to explicitly add an interface before he can >>> use the radio, can we not restrict him to one interface per radio at >>> any given time, thereby preventing the aforementioned confusion? >> >> No. At this moment IEEE 802.15.4 does not qualify as a sane default, >> because MAC implementation is far from being complete. And no, we >> must not restrict user in allocating one interface per radio. >> >> BTW: mac80211 (which we used as a model to follow in some points) >> does not have any restrictions on its own in this area. Most of the >> restrictions >> come from hardware. And even in that case it is usually possible to allocate >> "ethernet" subif together with "monitor" subif. >> >> -- >> With best wishes >> Dmitry > > > > -- > Regards, > > Prajosh Premdas -- 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
