IRC channel logs
2021-03-17.log
back to list of logs
<youpi>I have seen so many different styles, and people so much clenched on their own that I just got used to just write code like what is around <damo22>i dont mind gnu style, it makes ifs look better when you have lots of && <damo22>i got a little bit further with the stat issue, there is file->ps->failed as well as ->flags <damo22>when i ignore the failed ones i get to see what the stat looks like <jrtc27>sure you get used to the gnu style but it's still objectively awful :P <youpi>style questions can never be objectif <damo22>it looks like the name of the process is missing <damo22>which may be because its a bootstrap task so has no path? <youpi>what exactly do you see missing? <youpi>ok but which variable is that? <damo22>i dont recall, i dont have my code here atm <youpi>it's not ugly, it's hilarious :) <damo22>made me think there was an indentation issue, but then i saw the brackets finally <youpi>damo22: my bet is rather on the argv rather than the set_exe thing <youpi>set_exe is only for /proc/$pid/exe <youpi>/proc/$pid/stat shows argv instead iirc <youpi>that's supposed to be set by e.g. _hurd_proc_init <youpi>Mmm, but ext2fs does _hurd_init instead of _hurd_proc_init <youpi>probably better put prints to make sure what ext2fs calls in diskfs_S_fsys_init: _hurd_init or _hurd_proc_init <youpi>in the latter case, that tells proc the argv <youpi>I don't see how ps would be able to show the cmdline of ext2fs otherwise, actualy <youpi>alternatively you could call proc_set_arg_locations by hand <youpi>that being said, like I said procps etc. should be robust against a missing argv <youpi>ah, possibly at some point ext2fs sets its proc port through _hurd_ports_set, which ends up calling _hurd_setproc which calls proc_set_arg_locations <youpi>but _hide_arguments could have been set to 1 anyway, so proc / procfs need to be robust against this <youpi>(even though yes, we want our pci-arbiter / rumpdisk to show up nicely in ps) ***Server sets mode: +nt
<damo22>can libmachdev call _hurd_proc_init instead? <damo22>i ignored ps->failed flags and i got : <damo22>root@zamhurd:~# cat /proc/5/stat <damo22>5 () S 1 1 1 0 0 0 0 0 0 0 20 4 0 0 10 -10 5 0 0 179974144 405 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 <damo22>_hurd_init was being called with NULL argv <damo22>i added it in but it still doesnt update proc <damo22>does argv get destroyed during parse? <youpi>damo22: which argv, which parse ? <damo22>im hoping it does not chew up the argv vector <damo22>in any case, i copied the argv[0] and created a machdev_argv <damo22>but i cant seem to get proc to see it <youpi>programs are not supposed to mangle their argv <youpi>they don't know how it's allocated <damo22> proc_set_exe (proc, program_invocation_short_name); <damo22>+ proc_set_arg_locations (proc, (vm_address_t)machdev_argv, (vm_address_t)environ); <damo22>i better print out machdev_argv[0] <youpi>it's not argv[0] that it wants, but argv <damo22>how do i copy a full argv vector <youpi>pas it as it is, as I said it's not supposed to move since only libc knows how it's allocated <damo22>it is being passed correctly now but the stat still fails on the EIO <damo22>and when i ignore the ps->failed it is empty string <youpi>does the proc_set_arg_locations call not return an error ? <youpi>perhaps check in proc itself what is happening in get_string_array <damo22> munmap ((caddr_t) *buf, *buflen); <youpi>that's in the proc task, not in the translator task <youpi>so that's freeing memory in the proc task, not in the translator task <youpi>only vm_deallocate can free memory from another task <youpi>(which would be a very delicate thing to do...) <damo22>yeah but i thought i passed the memory address from the other tasks' argv <youpi>yes but what vm_read does is reading there, not taking it <youpi>it returns the read data in the data parameter <youpi>and buf is an allocation of the caller <youpi>(basically, the RPC that libps calls) <damo22>i thought the p->p_argv is passed in to that function <youpi>yes but merely as a parameter for vm_read to know where to read in the process <youpi>it doesn't tinker with the target process <youpi>The function 'vm_read' allows one task's virtual memory to be read <youpi> by another task. The TARGET_TASK is the task whose memory is to be <youpi> read. ADDRESS is the first address to be read <damo22>so if munmap( *buf, *buflen) is called and buf == p->p_argv, it does not unmap the memory behind the argv? <youpi>where do you see p_argv being passed as buf ? <damo22>what about S_proc_set_exe trying to free program_name_short_invocation ? <youpi>only libc knows how that's allocated <youpi>but where do you see it freeing this? <youpi>err, to avoid a memleak, simply? <youpi>that's the real meat of hardware without high-level abstractions, yes <damo22>i called _hurd_init (0, machdev_argv, portarray, INIT_PORT_MAX, NULL, 0); <damo22>i think hurd_init calls hurd_new_proc_init <youpi>see its source code in glibc's hurd/hurdinit.c <damo22> /* Tell the proc server we exist, if it does. */ <damo22> if (portarray[INIT_PORT_PROC] != MACH_PORT_NULL) <damo22> _hurd_new_proc_init (argv, intarray, intarraysize); <youpi>aaah, I remember that refactoring <youpi>I hadn't realized that _hurd_init is getting called from outside glibc <damo22>_hurd_init() and _hurd_proc_init () ? <youpi>in the current Debian version, no, _hurd_init is still as you saw it previously <youpi>so for the moment, your _hurd_init call should be enough <damo22>thats even more confusing, because _hurd_init should be calling the proc one in debian, where can i put prints? <youpi>you can rebuild debian's glibc package but that's long and you don't really need it, you can put prints in the S_set_arg_locations function in proc 