***valerius_ is now known as valeriusN
***valeriusN is now known as valerius
<damo22>youpi: i cant seem to figure this out. It seems that none of the calls to S_proc_set_arg_locations() fail to set the args <damo22>so at least one call to it is setting a strange arg <damo22>could it be that S_fsys_init is the wrong place to set the args for rumpdisk in libmachdev? <damo22>so it tries to set it for ext2fs <damo22>and rumpdisk's process args gets missed <damo22>start pci-arbiter: pci pci-arbiter: ../../libmachdev/trivfs_server.c:567: machdev_trivfs_server: Assertion 'proc' failed. <---- getproc() fails in the libmachdev if its not called in fsys_init() <damo22>how should the bootstrap filesystem (pci-arbiter) initialise proc? <damo22>i think its a base case of the recursion into fsys_init that is not working <damo22>there seems to be a bug where the ext2fs process /proc/7/status is having its name overwritten with "rumpdisk" but it should be populated in /proc/6/status <damo22>looks like the proc_set_arg_locations() is being set on the wrong process <damo22>or could be a bug remaining from transitioning to more bootstrap processes? <damo22>i think with arbiter+rump, it should be 6=>rumpdisk, 7=>ext2fs <damo22>somehow /hurd/startup is showing up twice <youpi>maybe also look at the rump-only case <youpi>to check which one brings the mess <damo22>mach_print( ((char **)argv)[0] ); <--- crashed proc when i tried to print the value of the argv inside S_proc_set_arg_locations ***joes_ is now known as joes
<youpi>so probably one of these calls passes NULL, and that's what needs to be tracked up <damo22>proc_set_arg_locations() is only called in startup/startup.c <damo22>once for the global proc process and twice for the kernel frob <youpi>It's also called in glibc's _hurd_new_proc_init <damo22>nowhere that i can see, so its 0