<damo22>hmmm when i dump_processes() in startup at the end of launch_core_servers() i get: <damo22>it seems pci-arbiter(5) and rumpdisk(6) are missing <damo22>im quite frustrated with this seemingly small problem <damo22>ive traced it back through various calls and all i can see is that proc_getprocargs is returning nonzero when you cat /proc/6/stat <damo22>and get_vector() is dying early and returning an empty buffer, its like the args are not populated <damo22>you cant call proc_mark_important() on a process that isnt a child of startup unless you are root, therefore startup cannot proc_child() rumpdisk <damo22>startup cannot call proc_child() on rumpdisk because it doesnt know which task to use <damo22>youpi: how do you make a process authenticated with auth so p->id is owned by root? <damo22>im hitting EPERM when i try to set proc_mark_important <damo22>i think one of the problems with the start up is that the bootstrap processes dont have a proper uid=0 credential ***cadmium.libera.chat sets mode: +o ChanServ
<youpi>damo22: AIUI from S_proc_mark_important, the idea is to first make it child of startup, and then use proc_mark_important <damo22>i did it by reauthenticating proc <damo22>now the process appears as root owned <damo22>but ext2fs' pid is being set with "rumpdisk" as exe <damo22>ess_tasks list is not populated yet with essential tasks inside launch_core_servers <damo22>do pids get renumbered at any time? <youpi>"i did it": making it child of startup ? That's unrelated to reauthentication <youpi>I mean this in S_proc_mark_important: p->p_parent != startup_proc <damo22>"it" being, passed the test in the condition, by passing the check_uid ==0 <youpi>I mean the comment in S_proc_mark_important seems to imply that for children of startup, they would not have uid == 0 at this point, and it'd rather be the parent == startup_proc test that would succeed <youpi>I guess it's simply the proc_child call? <damo22>ok, but how do i get a list of the tasks <youpi>check in the bootstrap.html page at which point you are <damo22>after the fsys_init() call in launch_core_serves <youpi>to know what was called, what was not <damo22>is fsys_init asynchronous? like are things happening in different threads or does it block? <youpi>see the beginning of diskfs_S_fsys_initdiskfs <youpi>even if fsys_init is synchronous, the diskfs call replies early <youpi>so it ends up being asynchronous <damo22>so how do i ensure i wait for the fsys_init chain to complete before checking ess_tasks <youpi>you watch for the startup_essential_task, see the code there that looks for the calls <damo22> startup_essential_task (startup, mach_task_self (), MACH_PORT_NULL, diskfs_server_name, host); <damo22>do i have to call fsys_init_reply (reply, replytype, 0); in libmachdev's trivfs_S_fsys_init() so it can send things to startup? <youpi>well ,you have the name so you can check what it is, and do the proc_child, mark important, etc. <youpi>that's what it does for exec for instance <damo22>ah you mean inside S_startup_essential_task() i can special case rumpdisk and pci-arbiter? <youpi>it's done for exec so I guess it won't cause trouble to do the same <damo22>it seems like a hack to do that because we may have more tasks to add to bootstrap <youpi>you could do the converse: exclude doing it for the names you know about <damo22>problem: if there is no pci-arbiter, how can you wait for it <damo22>like if you launch the system with different bootstrap processes, you need to know which ones to expect <youpi>damo22: what do you want to wait it for? <damo22>if (authinit && execinit && procinit) { launch_system <damo22>it also sends the reply for startup <youpi>diskfs_S_fsys_init waits for its own fsys_init call before calling startup_essential_task <youpi>so that don't have to wait for all of them, just one of them, that happens to only call startup_essential_task once bootstrap before it is over <youpi>I guess you could just add fsinit to the list <damo22>i think S_startup_essential_task is crazy, it allows for the three messages to arrive in any order, and then sets flags until they are all complete <youpi>well the initialization is crazy: bootstrap processes may have their own dependencies, so the order in which they can eventually be initialized may depend on other stuff <youpi>so it's better for startup to not impose any strict order <youpi>and just let them initialize in the order they prefer <youpi>that relaxes constraints for the rest of the boostrap process <damo22>but the problem i face now, is that i dont know which bootstrap fstasks to wait for <damo22>i can hardcode it to pci-arbiter and rumpdisk <damo22>but then it wont work if you run without the arbiter for example <youpi>as I said you don't need to explicitly wait for a list <youpi>you can assume that fs is the ealiest in the chain you have to wait for <damo22>so if ext2fs is completed, i can assume everything that launched it is complete <damo22>lrwxrwxrwx 0 4294967295 root 11 Jan 1 1970 /proc/5/exe -> pci-arbiter <damo22>lrwxrwxrwx 0 4294967295 root 8 Jan 1 1970 /proc/6/exe -> rumpdisk <damo22>lrwxrwxrwx 0 4294967295 root 2 Jan 1 1970 /proc/7/exe -> fs <damo22>that is correct but /proc/6/stat is still an error <damo22>maybe i should post what i have that fixes the "exe" <damo22>youpi: are you sure that proc_set_arg_locations() is being called for machdev_argv in glibc if i call _hurd_init(...) <youpi>trivfs_S_fsys_init has procserver != NULL, right? it then calls _hurd_init, which calls _hurd_new_proc_init, which calls __proc_set_arg_locations <youpi>mach_print() would allow you to be sure what happens <damo22>ok, with my changes, the machine shuts down at least after the rpc times out for pci-arbiter shutdown notification <damo22>the problem with the notification is that the disk access is terminated when rump shuts down, and then the arbiter cannot be contacted? <youpi>why can't it be contacted? what actually happens? <damo22>or something is happening after the rump shuts down <damo22>startup: notifying pci-arbiter of reboot... <damo22>then the rpc times out and it reboots <youpi>you can use the mach debugguer to check the state of pci-arbiter <damo22>interesting, it does not kill all tasks <damo22>but there is no more disk access <damo22>maybe its because the proc/6/stat is still broken <youpi>I'd say first fist stat, in case that happens to fix other things <damo22>i might send in this patch that fixes the proc/?/exe at least <damo22>do we need to fiddle with rumpdisk arg locations due to this? <damo22> /* The kernel task has a bootstrap port set. Perhaps it is its proc <damo22> server port from another Hurd. If so, propagate the kernel <damo22> argument locations from that Hurd rather than diddling with the <damo22>it calls proc_get_arg_locations (kbs, &kargv, &kenvp); and then sets them in another process with proc_set_arg_locations (proc, kargv, kenvp); <youpi>you are not running a sub-hurd