Josef,
[…] Admittedly I was also thinking of some unusual scenarios, such as
multiple wifi adapters where it makes sense to have one supplicant and multiple drivers. But that's strange enough maybe it doesn't need to be supported.
At least from my perspective I would rather treat the supplicant as a “minor” detail of the driver itself. So each instance has its own supplicant and a management component could take care of the overall configuration on the system level for multiple wireless devices.
Ok, I guess that makes sense.
However, I enabled the RT2800USB driver [0], added a 'wifi_ath9k.run' run script based on 'pc/run/wifi.run' to ease testing and will use this for further testing and development before tackling the Sculpt integration.
Ok, I may give this a look with the ath9k that I have already, it could be a great help in reducing compile time versus the depot builds.
I also had to adapt the test-bed somewhat [1] as the driver still requires the Platform session - removing this hard dependency is one of the tasks I implied by the PCI/USB split.
I'm not quite sure why this is for RT2800, it was not necessary for ath9k?
So far the RT2800USB driver is non-working and the next step is figuring out why. For that I will take a closer look at your USB back-end work and its integration into the kernel.
Bummer. I may pick one up too (i.e. RT2800-based device), they don't look pricey.
(Bare with me as this is done in my spare time, it might take a while.)
Sure, same.
-CVP