[CC'ing more people for a wider discussion]
On Sat, 2008-12-06 at 07:26 -0800, Igor Trindade Oliveira wrote:
> i was seeing your description about mac80211 hwsim in kernelnewbies
> and i see something about mac80211 userspace API.
> you can explain your idea?
I think the userspace API idea is probably not a good idea as is, it
makes it very complicated to program things, I guess hwsim should be
extended instead.
One thing I was especially looking for is, instead of having "virtual
air" inside the kernel, have "virtual air" in userspace.
For example, consider this scenario with three mesh points:
MP1 ---- MP2 ---- MP3
where MP1 and MP3 cannot directly communicate because they are too far
apart, physically. It isn't possible to test such a scenario with hwsim
because hwsim has no concept of distance.
One easy solution to this would be to introduce "air groups", each just
a number. In mac80211_hwsim_tx_frame, we have:
list_for_each_entry(data2, &hwsim_radios, list) {
struct sk_buff *nskb;
if (data == data2)
continue;
if (!data2->started || !data2->radio_enabled ||
!hwsim_ps_rx_ok(data2, skb) ||
data->channel->center_freq != data2->channel->center_freq)
continue;
The easiest way to do "air groups" would be to add:
if (!(data->airgroups & data2->airgroups))
continue;
and have the "airgroups" value be a u32 (or u64?) which can be modified
in configfs and defaults to 1. That way, you can have up to 32 (64)
groups (each bit being a group) and the above picture would become:
virtual device: MP1 ---- MP2 ---- MP3
airgroups: 1 3 2
Does that make sense? Do you think it's flexible enough? Should we maybe
use a u64 so we have more flexibility? It should be fairly easy to do
this, I think.
Of course, this isn't as general as it could be. I suppose some testing
scenarios will require simulating packet loss and similar, so we'll want
to have userspace make the decision about which packets get to which
radios. For this, you'd want to have a radiotap interface per virtual
hardware, which shows all frames transmitted by this virtual hardware
and, when frames are sent into that interface, the frame is given to
mac80211.
That would be the most generic way, but since it's also a lot more
complex I think there still is value in having the "airgroups" above,
especially since if we implement this idea then we still need a way to
decouple the virtual radios from the "virtual air" that's implemented in
the kernel, which perfectly fits with setting all "airgroups" to zero
which makes the "virtual air" in the kernel that I quoted above do
nothing.
Thoughts?
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
