Re: Building Screenshots and examples

Philipp Eppelt <[email protected]> Thu, 7 Nov 2024 10:20:04 +0100
Newsgroups	gmane.comp.micro-kernel.l4.devel
Message-ID	<[email protected]>
Hi Lonnie,

Am 06.11.24 um 23:02 schrieb Lonnie Cumberland:
> Hello Philipp,
> 
> Thanks for the information on the paths and ham. I am now working through things 
> to try and get a better feel on the general process as it is not yet clear to me 
> but getting better each day, with the guidance that you have provided me.
> 
> Probably like most people, I am generally always initially interested in seeing 
> as many different examples run when initially exploring software packages as it 
> gives me an idea as to the capabilities as well as how it all might be used 
> towards the projects that I am working on now.
> 
> With that in mind, I will explore the "make qemu" examples to see what it takes 
> to get them to run.  I am particularity interested in GUI applications and 
> things that might use framebuffers which is why I am very interested in the 
> "screenshot" on the L4Re website and maybe even replicating some of them even 
> though those are a bit old now.

Examples with GUI are the framebuffer-example and L4Linux-mag. mag is a 
framebuffer multiplexer. mag is not on github, but it is part of the 
2024.08-snapshot at https://l4re.org/download/snapshots/.
In the snapshot its at src/l4/pkg/mag. I haven't worked with mag, so I can't 
tell more about it.

You might be able to just copy the pkg/mag directory to the sources acquired 
from github, but bear in mind that the github release is a development state and 
these might not fit together anymore (but I just see one commit on top since 
August, I'm optimistic).

Unfortunately, I can't tell you more about these screenshots. I don't know from 
which setups they were created.


> 
> I would really like to see some microhypervisor examples that perhaps use 
> framebuffers as well, if that is possible, and to maybe even run something in 
> qemu first, after which then maybe to boot up a Live ISO on some real hardware 
> to see it work there as well since my project is towards a very lightweight 
> microhypervisor which will allow you to Hot-Key between VM consoles that have 
> GUI's running perhaps.I am thinking that maybe a PoC that can auto-start 1 VM 
> (with GUI) and then dynamically be able to start more, after which to be able to 
> toggle between each VM GUI console with a hotkey. Maybe also be able to use a 
> hotkey to terminate and destroy a VM am as well, or something along these 
> lines.  My key goals are to have it run Live (RAMDISK based) and keeping the 
> core microhypervisor footprint as small as possible.

That's a very nice project. It comes with a learning curve and has its coding 
challenges. :-)

Cheers,
Philipp

> 
> Until then, I will just continue to explore L4Re more since I truly think that 
> it is what I have been seeking for a number of years now, for this project 
> effort to finally get going. >
> Best Regards and have a great evening, my friend.
> Lonnie
> 
> 
> On 11/6/2024 12:29 PM, Philipp Eppelt wrote:
>> Hi Lonnie,
>>
>> it works with copying stuff to the assets directory, because the assets 
>> directory path is in the MODULE_SEARCH_PATH aka the list of paths printed in 
>> the error output.
>>
>> You can configure the MODULE_SEARCH_PATH and also the QEMU command line via 
>> the conf/Makeconf.boot file. Have a look at
>> https://github.com/kernkonzept/manifest/wiki/LinuxVM#creating-makeconfboot
>> and
>> https://github.com/kernkonzept/manifest/wiki/LinuxVM#creating-makeconfboot
>>
>>
>> So to get fiasco automatically picked up you need to specify something like
>>
>> MODULE_SEARCH_PATH += /path/to/fiasco/build/dir
>>
>> (e.g. line 26 in 
>> https://github.com/kernkonzept/mk/blob/master/conf/Makeconf.boot.example)
>>
>> The same applies to directories that contain binaries not found. Just add the 
>> directory paths in the same way to the MODULE_SEARCH_PATH separated by a colon.
>>
>> The list `make qemu` shows is generated from the entries in 
>> l4/conf/modules.list, so make sure to have all folders containing the 
>> mentioned files in the MODULE_SEARCH_PATH.
>> (Yes, these paths should be in the MODULE_SEARCH_PATH from the start, I'll see 
>> that this gets more beginner friendly.)
>>
>>
>> Regarding ham:
>> Yes, you can use any directory to check out into and there is no relation to 
>> the location of the ham binary. I myself have the same ~/bin/ham file which 
>> links to ~/code/ham/ham and my folder for the checkout is ~/code/l4/public.
>>
>> ham init -u ... generated a ~/code/l4/public/.ham and
>> ham sync generated ~/code/l4/public/{fiasco,l4} folders.
>>
>> However, note that `ham init` uses the _current directory_ to place the .ham 
>> directory into. `ham sync` than places the files in parallel to the .ham 
>> directory.
>>
>>
>> Cheers,
>> Philipp
>>
>>
>> Am 05.11.24 um 21:41 schrieb Lonnie Cumberland:
>>> Hello Phillip,
>>>
>>> Just as a quick follow up, I was able to put fiasco in the assets path, but 
>>> also had to copy some configs over from the examples in src after which I 
>>> could run some of them to run, but not many as they were missing some other 
>>> files as well.
>>>
>>> I am particularly interested in running framebuffer examples with the uvmm 
>>> and multiple VM's active at once on x64 if at all possible.  Some other 
>>> microhypervisor examples with graphics would also be very interesting to see 
>>> run as well.
>>>
>>> Thanks again and have a great day,
>>> Lonnie
>>>
>>>
>>> On 11/5/2024 3:22 PM, Lonnie Cumberland wrote:
>>>> Hello Phillip,
>>>>
>>>> Thanks for getting back to me on these and I have been able to confirm that 
>>>> the  .elf32 bit versions do run in qemu which is a good step forward and the 
>>>> .efi (x64) version do not at this time as you mentioned.
>>>>
>>>> regarding the "make qemu" I am able to bring up the list, but when I select 
>>>> one (actually all of them behave like this), I get an error:
>>>>
>>>> ---------------------------------------------------
>>>> Could not find
>>>>   'fiasco'
>>>>
>>>> within paths
>>>>
>>>>   /home/lonnie/build-amd64/assets
>>>>   /home/lonnie/build-amd64/bin/amd64_gen/l4f
>>>>   /home/lonnie/build-amd64/bin/amd64_gen/plain
>>>>   /home/lonnie/build-amd64/lib/amd64_gen/std/l4f
>>>>   /home/lonnie/build-amd64/lib/amd64_gen/std/plain
>>>> make[1]: *** [Makefile:693: qemu] Error 1
>>>> make[1]: Leaving directory '/home/lonnie/l4'
>>>> make: *** [Makefile:6: do-all-make-goals] Error 2
>>>>
>>>> ---------------------------------------------------
>>>>
>>>> My fresh setup is via ham and as per the steps 
>>>> "https://github.com/kernkonzept/manifest/wiki/BUILDING"
>>>>
>>>> I put ham in my ~/bin/ham and then added it to the PATH so that it is able 
>>>> to be used.
>>>>
>>>> On a side question regarding ham, I did try to create a "~/l4re" directory 
>>>> and then did the ham init from within there thinking that it might put all 
>>>> of the L4Re related directories under that initial sub-directory, but it did 
>>>> not and put them under my base home directory.  Is there some cli switch or 
>>>> flag that I can use to have ham put everything in the l4re sub-directory and 
>>>> build in there instead. This is not critical, but mostly just to keep all of 
>>>> the l4re stuff together and in one sub-directory for good housekeeping, I 
>>>> guess?
>>>>
>>>> Thanks again and have a great day,
>>>> Lonie
>>>>
>>>> On 11/5/2024 7:40 AM, Philipp Eppelt wrote:
>>>>> Hi Lonnie,
>>>>>
>>>>> welcome to the L4Re learning curve. :-)
>>>>>
>>>>> Indeed, there seems to be a problem with .efi images. Thanks for letting us 
>>>>> know.
>>>>>
>>>>> I can boot the .elf32 image though:
>>>>>     l4image -i l4re_vm-basic-pci.elf32 launch
>>>>>
>>>>> It behaves like shown in the screencast:
>>>>> https://l4re.org/cast-vm-basic-pci-qemu-x86.html
>>>>>
>>>>> Since you already have the github version, you can run the examples from 
>>>>> the l4re build directory. `make qemu` executed in your l4re build directory 
>>>>> should show a list of example entries to run. These examples are the same 
>>>>> as the prebuild images.
>>>>>
>>>>> Cheers,
>>>>> Philipp
>>>>>
>>>>>
>>>>> Am 03.11.24 um 21:52 schrieb Lonnie Cumberland:
>>>>>> Hello All,
>>>>>>
>>>>>> I hope that your day is going well.
>>>>>> Recently, I have decided to explore L4Re as a microhypervisor and 
>>>>>> capabilities as a possible minimalist component-based microkernel OS.
>>>>>>
>>>>>> I have just set up Ubuntu 23.10 (x64) in an Intel NUC13 and would am 
>>>>>> reviewing as much documentation as I can find as well as am building the 
>>>>>> core L4Re according to the Github Wiki just to see how the process goes.
>>>>>>
>>>>>> https://github.com/kernkonzept/manifest/wiki/BUILDING
>>>>>>
>>>>>> As I am in the learning curve at the moment, I also would like to build 
>>>>>> some examples such as the "Screenshots" (https://l4re.org/screens.html) 
>>>>>> and demos from the Pre-Built section 
>>>>>> (https://l4re.org/download/snapshots/pre-built-images/amd64/). I did try 
>>>>>> to follow the direction on the pre-built sections and grabbed the 
>>>>>> "l4image" and all of the AMD64 EFI files to try and test, but when I 
>>>>>> launch them they just seem to hang and do nothing.  I do have qemu (x64) 
>>>>>> installed as well, but still nothing seems to boot.
>>>>>>
>>>>>> What I would like to ask the mailinglist members is where can I get the 
>>>>>> source code to the "screenshots" examples as well as the AMD64 "pre-built" 
>>>>>> examples noted above so that I cam do a fresh compile to see them in action?
>>>>>>
>>>>>> Any help would be greatly appreciated.
>>>>>>
>>>>>> Thanks in advance and have a great day,
>>>>>> Lonnie
>>>>>>
>>>>>> _______________________________________________
>>>>>> l4-hackers mailing list -- [email protected]
>>>>>> To unsubscribe send an email to [email protected]
>>>>>
>>>>
>>>
>>
> 

-- 
[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

_______________________________________________
l4-hackers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
OpenPGP_signature.asc (application/pgp-signature, 840 B)