Hello, Svante Signell, le dim. 02 déc. 2018 17:06:17 +0100, a ecrit: > On Mon, 2016-02-08 at 23:33 +0100, Samuel Thibault wrote: > > Svante Signell, on Mon 08 Feb 2016 12:51:42 +0100, wrote: > > > 1) Locks are inherited by fork, they should not. Test program: libfshelp- > > > tests/fork.c > > > > As I mentioned previously, this should be fine for now. > > > > > 2) The pid of a conflicting process locking a file is not returned. > > > > Similarly, we can make GETLK return ENOSYS in glibc for now, that should > > be fine for now, as long as we already introduce in the RPC API the > > token needed for: > > > > > Both problems will be solved by implementation of the > > > proc_user_identify/proc_server_identify RPCs with corresponding > > > adjustments > > > to the code in this patch. > > I'm about to add an argument to the RPC, see below: > > /* Do fcntl type locking on FILE. CMD is from the set > F_GETLK64, F_SETLK64, F_SETLKW64. FLOCK64 is passed > by the user and is as defined by <fcntl.h>. */ > routine file_record_lock ( > file: file_t; > RPT > cmd: int; > inout flock64: flock_t; > <new entry here> > ); > > Any ideas what to call it, type in/out/inout and description?
As mentioned in my mail dated 20th Dec 2016, it's like io_reauthenticate, so rendezvous: mach_port_send_t to which you'd pass MACH_PORT_NULL for now. And in the server, in the GETLK case, set the l_pid field to -1 for now. Samuel
