Hi Colin,
On Wed, Feb 12, 2020 at 04:28:10AM +0000, Colin Parker wrote:
Hi Stefan, Thank you so much!
you are more than welcome ;-)
I think in case of networking, you can expose the network facility of the guest OS, which uses the dedicated USB-Wifi card, via the virtual NIC provided by Virtualbox. The nic_router component in Genode should be able to mark the domain of your guest OS to be the uplink for other domains. With the corresponding routing rules within your guest Linux you should be able to route requests from other Genode components to the USB-Wifi card. Of course, this is a functional solution, but not a favored one with respect to minimal complexity ;-).
Indeed, I was able to get this working. I am able to write this message from within a TinyCore VM, which is connected through Sculpt to a Debian VM.
That is so cool to read.
It is as you say not ideal, and it takes a bit of setup, but that's partly because Debian is not configured to act as a router by default. The routing within Sculpt was not so difficult once I understood the concept that "policy" can be used in place of "uplink" and still provides network to the outside world. However, the way I made it work was to replace the /config/managed/nic_router with /config/nic_router, but it then displays only "Local" under Network in the Leitzentrale. This works for the VMs but has the side effect that the depot cannot be accessed by Sculpt. Do you know if the launcher (or whatever other part if I misunderstood) can be "fooled" into attempting to download from depot even when it thinks the connection is local?
Well, I'm afraid the sculpt_manager cannot be easily fooled. It parses the state report of the nic_router, and depending on its uplink configuration senses the target configuration "wifi", "wired", "local", and "off". The problem is more than it is a bit too rigide, because we did not see your use-case in the first place.
I think it is ok in general to check as sculpt_manager whether the configured uplink domain got a valid IP address, and thereby decide whether networking works for the depot. I've prepared an untested commit, which you could test out in your scenario by rebuilding the sculpt_manager. Here is the commit:
https://github.com/skalk/genode/commit/1eec61843905ef85c12be08c8405f7a04741a...
You can rebuild your sculpt image by tweaking the sculpt.run script to always compile and integrate the sculpt manager to incorporate the commit without the need to rebuild the whole package by applying this patch:
--- PATCH START ---
diff --git a/repos/gems/run/sculpt.run b/repos/gems/run/sculpt.run index 546a63cc39..618c3b9518 100644 --- a/repos/gems/run/sculpt.run +++ b/repos/gems/run/sculpt.run @@ -668,6 +668,7 @@ exec sh -c "tar cf [run_dir]/genode/depot_users.tar -C [genode_dir] \ # Create boot image #
-append boot_modules { } +build { app/sculpt_manager } +append boot_modules { sculpt_manager }
build_boot_image $boot_modules
--- PATCH END ---
I hope this helps.
P.S. Eventually it would be good to replace Debian with a very small VM just dedicated to the WiFi driver, can the Sculpt version of vbox or seoul run headless?
I've never tested it, but I would expect that you can tweak the machine description (XML description in machine.vbox file) of your Virtualbox instance to not define any display. It should then do not open a session to the Nitpicker service (GUI service) - theoretically. To circumvent the opening of a window, you must tweak the existing vbox5-nova-sculpt package or replace it with one, which does not use the Nitpicker service and does not spawn a nit_fb component.
But be aware, that you cannot access the VM in this case, except via networking. There is no UART model or similar, which uses Genode's Terminal service as backend in our VirtualBox port AFAIK. With respect to seoul I actually have no experiences at all.
Best regards Stefan
Regards, Colin
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users