IRC channel logs


back to list of logs

***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>ok that is where i am confused
<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>to set the exe
<youpi>ah, that, yes
<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
<youpi>does the rpc get called?
<damo22>getproc does not return error
<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>i checked p->p_pid == 5 or 6
<damo22>and no print occurred
<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);
<damo22>thats the only warning
<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
<damo22>for set_arg_locations
<damo22>This call can be made only once
<damo22> per task. */
<damo22>routine proc_child (
<damo22>maybe i am calling it twice
<youpi>how so?
<youpi>only startup calls it, doesn't it ?
<damo22>i changed startup such that it iterates through pids
<damo22>and finds the essential tasks
<youpi>anyway, you can print to make sure
<damo22>but i dont know why the rpc is missing
<damo22>the call to it i mean
<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>oh yea
<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> RPC just as init would. */
<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
<damo22>thank you!
<youpi>you get the parent_task from fsys_getpriv
<youpi>(in machdev_trivfs_init)
<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
<youpi>see how libdiskfs does it
<damo22>proc_mark_important fails with operation not permitted
<damo22>for the arbiter
<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
<damo22>in set_arg_locations
<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
<damo22>it has the real procserver?
<youpi>it doesn't have an fsys_init() call to do
<youpi>let me restate precisely
<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>that is completely fine
<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>in that line
<youpi>which line?
<damo22>portarray[INIT_PORT_PROC] = procserver
<youpi>that'd be meaningless
<youpi>getproc() *READS* portarray[INIT_PROT_PROC]
<youpi>we are setting portarray precisely for getproc() to work at all
<youpi>really, that line is fine
<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>just like libdiskfs does
<youpi>really, just do like diskfs does
<youpi>diverging code will be even more confusing for other people coming later
<damo22> <-- this almost works but sets pid 5 twice
<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>noinà gre g gl*
<youpi>just fix the damn fsys_inti call
<youpi>I mean the caller*** not the callee**
<youpi>in machdev_trivfs_init
<youpi>ergl sorry, I mixed things
<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
<damo22>thanks for your help
<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>Maybe it is a global variable?
<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??