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? Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
