Hello Colin,
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).
[0] https://github.com/cnuke/genode/commits/pc_wifi_drv-ath9k-2023-01-15
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.
[1] https://github.com/cnuke/genode/commits/ath9k_driver_support-2023-01-15
(As it turned out I might have misremembered as the USB wifi dongle I own is apparently an Ralink rt2800usb device and not a Realtek one, which should not matter though.)
Yes. Regarding splitting up the components, a thought I had was to make the 'wifi_supplicant' a separate Genode component. Since it already runs as a separate thread using a shared buffer and semaphores, it shouldn't be too difficult to split it as its own component. The advantages would be that all interfacing of sculpt_manager with the supplicant would be common across drivers, making it easier to port more drivers, and each driver would inherit the same feature set of the supplicant (e.g. if ad-hoc mode were enabled it would not require much, if any, change to the drivers).
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.
As you probably have noticed we have some ported USB device drivers, albeit using the legacy lx_kit/lx_emul implementation, that share the glue-code. Eventually we want to update them as well - so by all means, if you have some ideas formed by your current experience feel free to share them.
Yes, I did see these drivers. My experience with the legacy lx_kit/lx_emul implementation has been much less positive than with the current version, sorry to say. My thoughts on porting USB drivers: […]
Thanks for your input, I will respond to that in time and keep it in mind only for now.
Regards Josef