Re: RFC: [PATCH hurd 1/6] Add file record locking support: libfshelp_rlock.patch

[Samuel Thibault]

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