<biblio>luckyluke: I was able to get the same error message. I am trying to understand overall X86 boothdr.S. Let me know if you want me to check any particular part of the boot process. ***duds-_ is now known as duds-
<slex>youpi: I'm getting better with gnumach, I just have a fast question. Then I will go to work. If i want pass the host_port to my hello server at boot, I don't need to parse anything riht? That is done by the boot_script.c and bootstrap.c by the kernel and then it passes that value as argument to the programs main? <luckyluke>biblio: I updated the code with linking the kernel at 0x40000000. Now the issue I have is when starting the first user-space task in stack_handoff, when activating the new pmap <luckyluke>I suppose something still need to be fixed on the page map, now that the kernel address range is not identity-mapped (see boothdr.S) <youpi>slex: it's the ${host-port} variable <youpi>the port is already there, the process just has to parse its command line to get the number <slex>youpi: yes ty, I looked more code today i had more time, i saw that host-port is defined with a value that is 2 and device port 1. The command line works as usual? Are the ports in the argv? so i parse that? I'm really near to second goal. At the begin i was thinking that the host-port and device-port was created dynamyc, i was wrong and i found in bootstrap those 2 #define, I'm really happy understanding stuff <youpi>slex: see ext2fs' main, it just parses its argv <slex>ok ty that's nice. That souldn't be long to do. After that i will need to to write a hello_client that will be able to send a message to the hello_server, if i really understood this probably need to be a child of the hello_server (where my hello server is acting as nameserver) <luckyluke>I was thinking recently about some kind of unit tests for gnumach, that could be run on qemu. It would load one or more statically-linked executables to test e.g. the tsak rpc, or vm, or anything. It could also be automated quite easily I think. <luckyluke>I'm using something similar to test my changes with gdb <biblio>luckyluke: The idea is good. But I am bit skeptical about how long this python project will be maintained. I would prefer other scripting languages those are more close with qemu api. <luckyluke>Pytest seems well maintained, the qemu plugin I don't know... But for few tests a shell script is probably enough <luckyluke>For many tests, with parameterization and so on, I think pytest is worth it <luckyluke>I'm not an expert in testing frameworks though...