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

[Svante Signell]

Missing features:

1) Locks are inherited by fork, they should not. Test program: libfshelp-
tests/fork.c
2) The pid of a conflicting process locking a file is not returned.

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. 

[Samuel Thibault]

+++ hurd-0.7.git20160114/libfshelp/rlock.h
+
+//#include <pthread.h>

Why not? That'd avoid copy/pasting the pthread_cond_init

+extern int pthread_cond_init (pthread_cond_t *__restrict cond,
+ const pthread_condattr_t *__restrict attr);

Please do take our questions & remarks into account, otherwise we can't
make progress.

Samuel

[Samuel Thibault]

Post by Svante Signell
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.

Post by Svante Signell
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

Post by Svante Signell
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. 

Samuel

[Svante Signell]

Post by Samuel Thibault

Post by Svante Signell
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.

Post by Svante Signell
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

Post by Svante Signell
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 didn't really grok your reply here:
Do you really mean I should update the glibc patch to return ENOSYS for GETLK
and that we can implement proc_user_identify/proc_server_identify RPCs and fix
the remaining issues for file record locking later on?

[Samuel Thibault]

Post by Svante Signell

Post by Samuel Thibault

Post by Svante Signell
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.

Post by Svante Signell
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

Post by Svante Signell
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. 

Do you really mean I should update the glibc patch to return ENOSYS for GETLK
and that we can implement proc_user_identify/proc_server_identify RPCs and fix
the remaining issues for file record locking later on?

Yes.

[Svante Signell]

Post by Samuel Thibault

Post by Svante Signell
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.

Post by Svante Signell
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

Post by Svante Signell
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? Of course the
implementations would return EOPNOTSUPP
until proc_user_identify/proc_server_identify RPCs are implemented.

Thanks!

[Samuel Thibault]

Hello,

Post by Svante Signell

Post by Samuel Thibault

Post by Svante Signell
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.

Post by Svante Signell
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

Post by Svante Signell
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.

/* 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

[Samuel Thibault]

Post by Samuel Thibault
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.

More precisely: in the server, for now set the field to -1 if the port
is null, and return EOPNOTSUPP if the port is not null.

Samuel