On Thu, 2015-03-05 at 02:34 +0100, Samuel Thibault wrote:
> Olaf was wondering about flock being reimplemented over this new
> implementation. It's actually a tricky question. I believe there are
> two issues:
>
>
> All in all, I'd suggest the following:
...
> - let's make GETLK however return ENOSYS: we can't fill the l_pid, and
> this is not worse than what we have ATM.
Is it OK to add to fcntl.diff?
- return __flock (fd, cmd);
+ err = HURD_FD_PORT_USE (d,
__file_record_lock (port, cmd, fl));
+ if (fl->l_pid == -1)
+ {
+
errno = ENOSYS;
+ err = -1;
+ }
+ result = err ?
__hurd_dfail (fd, err) : 0;
(and in one other place)
> - let's already put the process token in the new RPC API. Setting it to
> non-NULL from the client will mean "I want a per-process lock", and
> for now let's return ENOSYS in that case.
Which RPC and which token name are you thinking of here?
> - later, we'll implement proper per-process locks, by using the token as an
> identifier of the process.
Which token?
> - we'll then be able to implement GETLK, and in case a per-open lock was
> taken, we'll put -1 in l_pid, like BSD does.
Please explain!
> - when per-opened file record locks get standardized, we can trivially
> implement it.
See above.
