Re: [PATCH] adding /proc/pid/exe
Hello, Samuel Thibault, on Mon 19 Dec 2016 14:38:25 +0100, wrote: > I'm notably wondering about the RPC: > should we be using string_t or data_t ? So, any opinion on this? > Index: hurd-debian/hurd/process.defs > === > --- hurd-debian.orig/hurd/process.defs > +++ hurd-debian/hurd/process.defs > @@ -413,3 +413,14 @@ routine proc_get_code ( > routine proc_make_task_namespace ( > process: process_t; > notify: mach_port_send_t); > + > +/* Set the process binary executable path. */ > +routine proc_set_exe ( > + process: process_t; > + path: string_t); > + > +/* Get the process binary executable path. */ > +routine proc_get_exe ( > + process: process_t; > + which: pid_t; > + out path: data_t, dealloc);
Re: Porting with Guix
Hello Rennes, Please pull the latest changes from my github repo, try again and report back. Manolis
Re: [PATCH] adding /proc/pid/exe
Samuel Thibault writes: > Hello, > > Samuel Thibault, on Mon 19 Dec 2016 14:38:25 +0100, wrote: >> I'm notably wondering about the RPC: >> should we be using string_t or data_t ? > > So, any opinion on this? I recommend just using string_t for now. Eventually, we need to salvage the string_t disaster (i.e. that string_t is a fixed-size char array which arbitrarily limits values like filenames and blows up message sizes). The annoying thing is that MIG does support variable-sized character arrays (iirc, the terminology for the Mach types could be different), so the Hurd could have used it in the first place. We could a) simply change it and rebuild clients and servers, or b) try to provide a smooth upgrade path. Justus signature.asc Description: PGP signature
