Re: [PATCH 0/3] Add mcast event when hwsim radios are created and removed

[Ben Greear <greearb@candelatech.com>]

On 10/27/2014 04:14 PM, Marcel Holtmann wrote:
> Hi Luca,
> 
>>>>>> That's not particularly hard to figure out, for example by looking at
>>>>>> sysfs.
>>>>>>
>>>>>> Is this really so time-constrained/important/... that you can't do that?
>>>>>
>>>>> It does not seem very practical to dig this information from sysfs as
>>>>> the same information can be easily get via netlink as this patch shows.
>>>>
>>>> Well, that's a slippery slope. I'd consider it more practical to use
>>>> existing APIs instead of (gratuitously) inventing new ones. It'll even
>>>> work on older kernels as an added benefit.
>>>
>>> I see that different. The component that handles the emulation of the new wireless device should be independent from the component driving it. I prefer to have a race free way of obtaining the needed information without having to monitor nl80211 and sysfs for this. Especially with the use cases that we have in mind it has no business with these other interfaces.
>>>
>>> We have been down this route with the bridge interface where people had to dig out information from sysfs and it did not work out nicely. So now everything moves to netlink.
>>
>> Why does hwsim have to be treated differently from any other device?
>> Unlike bridging, HW emulation doesn't seem to be a real life use case.
>>
>> But I'm probably missing something. ;)
> 
> this is the controlling side. The thing that I call emulator. It is the component that creates/destroys the hwsim wiphy. It can also be the one that handles the packet processing similar to wmediumd.
> 
> The nl80211/cfg80211 is not treated differently here. This is purely for the MAC80211_HWSIM netlink family side of things. Makes sense?

I just got some patches accepted upstream that allow you to name the phy upon creation
(and to suppress wlanX creation in case that is desired).

If your control tool is creating the phys, then it can know ahead of time the names
and match the events that way.

I'm not taking sides on your particular patch, but those features made my
tool a lot easier to write and more efficient.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com