***Server sets mode: +nt
***DiffieHellman_ is now known as DiffieHellman
<damo22>when you call proc_set_exe(proc, ...) is the first variable supposed to be proc = getproc(); so it gets the current process? <damo22>or is it supposed to be the process of the procserver? <youpi>getproc() doesn't return the current process, it returns a porton the procserver <damo22>so do i need to call it on the current process? <youpi>what do you call "the current process" ? <damo22>eg, in machdev, do i need to get the process_t of mach_task_self() ? <damo22>ok thats why its not working then <damo22>i am using getproc() as the proc <damo22>so i am changing the exe and args of the proc server <youpi>getproc() does return the process_t for the current process <youpi>see e.g. utils/frobauth.c: error_t err = proc_getloginid (getproc (), getpid (), &lid); <damo22>err, you contradicted yourself just now but ok <youpi>I thought by "current process" you meant "current task" <damo22>im not sure why its not working then <damo22>S_proc_set_arg_locations gets called heaps <youpi>are you talking about set_exe or set_arg_locations? <damo22>both, i am calling them one by one <youpi>but are you seeing the set_exe rpc getting called? <damo22>i dont know because it gets called so much for every process <youpi>you can put a number limit in the print <damo22>set_arg_locations did not fail ever <damo22>but i dont know if it was called for sure for rumpdisk/arbiter <damo22>looks like it did not call the rpc <damo22>could it be missing a mig-mutate thing? <youpi>mig-mutate is on the server side <damo22>i got a warning when compiling machdev <youpi>that's not supposed to depend on the particular client that called the RPC <youpi>ah, thou shall fix warnings, yes <damo22>mach_i386Server.c: In function ‘_Xi386_io_perm_create’: <damo22>mach_i386Server.c:325:17: warning: implicit declaration of function ‘ports_payload_get_name’ [-Wimplicit-function-declaration] <damo22> 325 | master_port = ports_payload_get_name(In0P->Head.msgh_protected_payload); <youpi>ok, it's just missing including ports.h <youpi>the function is there, and even with the default prototype that should be working <damo22>so the print occurs without rumpdisk bootstrap for pid 5 and 6 but when i boot with rumpdisk, there is no rpc called <youpi>only startup calls it, doesn't it ? <damo22>i changed startup such that it iterates through pids <youpi>anyway, you can print to make sure <damo22>but i dont know why the rpc is missing <youpi>you can also put prints around the call <youpi>to make sure that the flow gets there, for a start <youpi>then if it doesn't show up in the server, it's possibly a problem with the port <youpi>or perhaps the server not listening yet <youpi>though normally at fsys_init time it is there <damo22>could it be because startup is single threaded and is blocking on the reply <youpi>if a server is blocked somehwer, that would block the RPC <youpi>not prevent it from running at all <youpi>anyway it's not startup which is concerned here, but proc <damo22>it prints out XX_ARGV_XX rumpdisk and pci-arbiter <youpi> /* Get the parent's proc server port so we can send it in the fsys_init <youpi> err = proc_task2proc (procserver, parent_task, &parent_proc); <youpi>libdiskfs does that before calling fsys_init <youpi>i.e. it doesn't transfer the proc port as such to the fsys_init call, it passes the proc port of its parent task to fsys_init <youpi>libmachdev's fsys_init call forward needs to do the same <youpi>you get the parent_task from fsys_getpriv <damo22>ah yes, and i do nothing with it <damo22>so do i call fsys_init with parent_proc as the procserver? <youpi>just like above, use proc_task2proc to get the process_t for the parent, from the parent_task <damo22>proc_mark_important fails with operation not permitted <youpi>&& p->p_parent != startup_proc) <youpi>so it seems proc_child needs to be done before that call? <damo22>i just ignored the EPERM like diskfs <damo22>it almost worked but pid 5 got called for both rumpdisk and the arbiter <youpi>possibly the getpriv forwarding doesn't provide the proper parent task <damo22>actually the arbiter has no parent <youpi>yes, and it doesn't have a bootstrap port either, so it doesn't need it <damo22>so is procserver the correct parent proc of the arbiter in the case where there is no bootstrap port? <damo22>maybe it is the only correct one <youpi>? the arbiter doesn't have any parent proc <youpi>that's fine, it doesn't need any <youpi>since it doesn't have a bootstrap port <youpi>it doesn't have an fsys_init() call to do <youpi>process_t is a port to the proce server, to make RPCs to the proc server. it happens to also be a way to represent a task when discussing with proc <youpi>so each task has its own port, to be able to communicate with proc, but also under the identity of the task <youpi>you can pass over a process_t port to another process, and then that process can call RPCs with proc, "under the identity" of the original task that passsed the port <damo22>portarray[INIT_PORT_PROC] = procserver; <--- does this need to be replaced with parent_proc in the case where it has a parent task? <youpi>so there is no notion of "real procserver" <youpi>it has to be the port for the current task <youpi>but when calling fsys_init(), it's the proc port for the parent task that you're supposed to give <youpi>so the parent gets it and record it for itself for its own use for its own task <damo22>i think the procserver variable should be replaced with getproc() <damo22>portarray[INIT_PORT_PROC] = procserver <youpi>getproc() *READS* portarray[INIT_PROT_PROC] <youpi>we are setting portarray precisely for getproc() to work at all <youpi>it takes the process_t port from the fsys_init() RPC call <youpi>which the caller carefully made the process_t for its parent, which is precisely the task it's calling fsys_init on <damo22>maybe i can call getpriv again in the rpc? <youpi>what for? that was already called before in the init functoin <youpi>there is no need to do it again, just record it in a global variable <youpi>really, just do like diskfs does <youpi>diverging code will be even more confusing for other people coming later <damo22>do i need a proc_child call somewhere? <youpi>that's not surprising as long as you haven't fixed the fsys_init() call <youpi>just fix the damn fsys_inti call <youpi>I mean the caller*** not the callee** <youpi>really, I can't do proper feedback while I'm at work <youpi>yes of course fsys_init is both the caller and the callee <youpi>so yes your fsys_init() call looks good now <youpi>I don't see why it's be doing it for pid5 twice, though <damo22>ok i will let you get back to work, sorry <gnu_srs1>damo22: Just an observation: From your paste, int the fsys_getroot call first argument control_port is never declared or used? <gnu_srs1>Seems to be declared in trivfs_server.c and set in trivfs_S_fsys_startup(). My bad! <gnu_srs1>But is does not seem to be called in: libmachdev/trivfs_server.c. It is called in libtrivfs/startup.c where also a stub of trivfs_S_fsys_startup() is defined??