IRC channel logs


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 do you call "name" ?
<youpi>what exactly do you see missing?
<damo22>in the stat: ()
<damo22>instead of (ext2fs)
<youpi>ok but which variable is that?
<youpi>in procfs
<damo22>i dont recall, i dont have my code here atm
<jrtc27>youpi: still sure is subjective? :)
<damo22>that is not gnu
<damo22>its ugly
<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>(I guess)
<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
<damo22>the argv from main
<youpi>programs are not supposed to mangle their argv
<youpi>they don't know how it's allocated
<damo22>ok good to know
<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>in machdev
<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
<damo22>or can i pass it argv itself
<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 ?
<damo22>ahh i didnt check
<damo22>no error
<youpi>perhaps check in proc itself what is happening in get_string_array
<damo22> if (*buf != origbuf)
<damo22> munmap ((caddr_t) *buf, *buflen);
<damo22>buf could be a argv
<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>vm_read *only* reads
<youpi>it doesn't tinker with the target process
<damo22>got it
<youpi>see pinfo mach
<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>ohh its loc not buf
<damo22>i missed a param
<damo22>what about S_proc_set_exe trying to free program_name_short_invocation ?
<damo22>will that break anything?
<youpi>only libc knows how that's allocated
<damo22>maybe it should not free it
<damo22>and live with the dup
<youpi>but where do you see it freeing this?
<damo22>it frees p->exe
<damo22>why does it do that?
<youpi>err, to avoid a memleak, simply?
<youpi>see how p->exe is set
<damo22>i really dont like C strings
<damo22>i always forget how it works
<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>? non
<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);
<damo22>or am i on some old glibc?
<youpi>that's _hurd_libc_proc_init
<damo22>ah i pulled glibc
<damo22>its different now
<damo22>it used to call it
<youpi>aaah, I remember that refactoring
<youpi>I hadn't realized that _hurd_init is getting called from outside glibc
<damo22>maybe i need to call both now
<damo22>in machdev?
<damo22>_hurd_init() and _hurd_proc_init () ?
<youpi>I'm checking
<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
<damo22>ok thanks
<damo22>gtg to sleep