Re: Porting apps to L4Re?
Hi Lonnie, Am 13.11.24 um 15:14 schrieb Lonnie via l4-hackers: Hello All, As part of the project effort that I am working on with L4Re, I am considering 2 possible pathways of which both need graphics capabilities to interact with the uvmm for a guest OS: Possible pathways: 1. Use the framebuffer "spectrum" example and port something like FreeRDP, rdesktop or other, so that this will allow for a loabable RDP service VM whose only job is to connect to other VM's. This would be for having a Docker/Podman Container engine running and to be able to connect to a container via a web browser VM that has a graphic console in fullscreen mode. I don't get it. You don't want to have a VM driving the screen/GPU but an l4re service like mag? And then there is a VM which gets a framebuffer to draw into and this shall connect to some other VMs. And then I'm lost in the container / web browser VM / console description. You can have a VM driving the GPU/screen, input and NIC. Together with virtio-net-switch all VMs can be on the same virtual network and then you could connect to them via your chosen network-based service. Is this something you considered? 2. Find a way to have L4Re be able to access the graphic console (VGA) of each uvmm guest directly and then be able to HotKey switch between active VM's. This might be like having multiple guest OS's running (i.e. Ubuntu 24.04 and Windows 10 for example) and then be able to switch the console between them. This is also an idea to allow L4Re to boot all of the OS's that might reside on a dualboot or multiboot system. When you implemented windows support into uvmm, please let me know ;-) Jokes aside, I haven't experimented with this, but there is some documentation about framebuffers in the uvmm documentation (pkg/uvmm/doc/uvmm.dox). I think mag should be able to serve your needs here. It can provide framebuffers and input multiplexing, but I don't know to which extent. It's been a while since I last used it. Wrt to booting OS from disk. Yes, this is possible, you need to configure uvmm to boot from these partitons and of course you need an l4re driver for the disks (ahci-driver or nvme-driver). These are the building blocks I see that should get you to do first experiments. Cheers, Philipp -- [email protected] - Tel. 0351-41 883 221 http://www.kernkonzept.com Kernkonzept GmbH. Sitz: Dresden. Amtsgericht Dresden, HRB 31129. Geschäftsführer: Dr.-Ing. Michael Hohmuth OpenPGP_signature.asc Description: OpenPGP digital signature ___ l4-hackers mailing list -- [email protected] To unsubscribe send an email to [email protected]
Re: Porting apps to L4Re?
On Wednesday, 13 November 2024 15:14:54 CET Lonnie via l4-hackers wrote: > > As part of the project effort that I am working on with L4Re, I am > considering 2 possible pathways of which both need graphics capabilities to > interact with the uvmm for a guest OS: As you may recall, having communicated with you earlier, I am not personally interested in running virtual machines under L4Re as such, even though I get the impression that this might account for the majority of L4Re users. If it isn't commercially super-sensitive, some indication of the user demographic for L4Re would be interesting to hear more about. But on the topic of porting programs to L4Re, I would regard the principal challenge as involving bulking out the library and framework support within L4Re itself. My own efforts have involved porting libext2fs, implementing a simple filesystem framework, and porting and adapting Newlib to allow fairly normal programs to run under L4Re, although it is (and will continue to be) a long, drawn-out process. I don't know what the current state of the library support is like in L4Re, but it has historically contained a lot of stubs for fairly common functions, and the filesystem integration struck me as very odd indeed, leading me to pursue my own path. My impression is that the L4Re library support is currently sufficent as a way of providing an embedded-style platform for components that live outside the virtual machines in a hypervisor or virtual machine manager environment, where all the real applications live inside those virtual machines. I do wonder what happened to the whole DROPS effort, what lessons were learned, and so on, though. And with regard to sustaining that effort, I suspect that a classic multi-server environment was unable to attract funding in the ever-changing landscape of fashion-driven funding and investment. Sorry if that isn't answering any of your questions, but any discussion of deploying programs on L4Re seemed too good to pass up! Paul ___ l4-hackers mailing list -- [email protected] To unsubscribe send an email to [email protected]
