Hi Josef,
I added the ath9k driver [0] to the 'pc_wifi_drv' driver where it worked
fine in my limited testing (with the one device I have at hand and the GSI/MSI quick-fix).
Good to hear. Was this done with the changes I made to the supplicant interface? I'm curious if those break the existing wifi functionality, which I can't test other than to say it compiles successfully.
I also started to look at your commits in more detail (I have split them up somewhat to get a better grasp of the changes [1] - for the commit in world I diff'ed the driver in pc and yours to get your adjustments and additions). I noticed that the 'pc_lx_extras' library code seems to be missing from your commit.
At some point I believe this was re-named by me to pc_lx_ath9k_extras. You should find it in world/lib/mk and the import file in world/lib/import. The only point as I remember is to add the necessary files from the linux contrib dir. Since the ath9k driver sits in world, rather than in "pc", the corresponding source.list and dep.list files are not imported automatically by pc_linux API, hence the need for the pc_lx_ath9k_extras API for depot builds, and the import-pc_lx_ath9k_extras file to correctly locate the imported files. But, I am a genode build/depot build newbie, so perhaps I made this too complicated? If you want to build in the "pc" repo itself I suppose it isn't needed.
I would not go as far as splitting the 'wpa_supplicant' from the driver for now. From Sculpt's perspective the wifi-management-layer ('Wifi::Frontend') is the interface to talk to. If ad-hoc mode or even host-ap functionality becomes a desired feature I would integrate support for that in this interface as well.
That being said, I entertain the idea of changing the inner workings of the wifi-management ↔ supplicant ↔ driver chain to get rid of the internal socket call interface or rather clean it up a bit.
Ok, understood. I'm not sure how much cleanup it even needs. As is, I think it will not be as difficult as I thought to update drivers in the face of changes to Wifi::Frontend, since basically one just needs to link to a different version of a shared library. 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.
BTW, were you able to build the wifi_ath9k_drv component? I hope that I have a version that is suitable for others to try. Well, if anyone has the hardware, which maybe is not as common as I thought since i bought it a while ago.