Hi All & Dmitry
Now i see your point there and understand the design better. But i
have a few more doubts.
Case #1: synchronous mlme commands(mlme_reset, mlme_get, mlme_set)
We(currently Felix and my self) are adding mac functionality. I will
just briefly describe you
1. my test setup
2. code flow for pib set (eg. set channel page)
Please confirm me that flow as expected. This will reduce a lot of rework too.
1. Test setup: AT91SAM9G20-EK + AT86RF231(wsn-phy0) and all the
modules correctly loaded.i describe a new device type
IEEE802154_DEV_WPAN with the ops structure initialized as
struct ieee802154_mlme_ops mac802154_mlme_device = {
.reset_req = mlme_reset_req,
.get_req = mlme_get_req,
.set_req = mlme_set_req,
.assoc_req = mlme_associate_req,
.assoc_resp = mlme_associate_resp,
.get_phy = mac802154_get_phy
};
I have created 2 net device interface wsn0 and wsn1 from the single
wsn-phy0 radio. both are of device type IEEE802154_DEV_WPAN
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.
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?
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
<[email protected]> wrote:
> On Fri, Mar 2, 2012 at 3:52 PM, Felix Varghese <[email protected]> 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
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
