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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
