On Mon, 2014-10-27 at 16:14 -0700, Marcel Holtmann wrote: > Hi Luca, Hi Marcel, > >>>>> 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? Ah, okay, I was confused. Makes total sense to me then, I don't see why we shouldn't have this API to provide the needed information totally independently from nl80211. -- Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
