new interfaces io_close, io_reidentify, file_record_lock

[Marcus Brinkmann]

Hi,

these are the new interfaces I am proposing as a first draft to prepare
POSIX record file locking and shared memory.  There has been some discussion
in the past, but I want to summarize the critical points why the interfaces
look the way they do.

io_close

* We need an optional io_close to synchronize a user with various events
  in the server related to closing a file descriptor.
* io_close needs to be interruptible.
* io_close does not need to be restartable, as the state of the FD after the
  interruption is unspecified by POSIX.  The easiest thing for us is to finish
  the close in the client and server asynchronously.  The client should drop
  the fd entry and return EBADF (because that is the error the user would get
  if he tried to restart, and we are not allowed to return EINTR if
  we are supposed to restart).  The server asynchronously completes the
  deallocation of the send right (ie, the destruction of the object).  In
  any case, this is only an issue for blocking close operations, like
  SO_LINGER sockets.
* The above means that we need a special client stub for libhurduser, but no
  special server stub.

io_reidentify, proc_user_identify, proc_server_identify

* We need a way to identify the iouser by its PID for POSIX record file
  locking and shared memory.  It's natural to have an auth like protocol in
  proc.
* The process_t process port in proc can be used by the user to call
  proc_user_identify on.  No flexibility is needed here.
* The server needs to pass a new identified port through proc - originally I
  thought we can just keep using the original user port, but that is
  introducing a short race between the user and server getting their reply.
  The user might use the old port before the server recorded the new PID of
  the user.
* What I don't know yet is if we need to reidentify all our I/O objects in
  glibc by default, or if it is good enough to just do it when we need to take
  the lock for a file.  It seems to be a waste to reidentify all objects.
  I am also not sure if we need a way to drop the identity (ie, get an
  "empty" process_t process from proc, which associates with an invalid pid,
  let's say -1).  I am also not sure if we need integration with dir_lookup
  to request a reidentification by the user.  All of this is probably
  irrelevant just to make it work properly for record file locking and
  shared memory.

file_record_lock

* This is absed on Neal's patch for record file locking.  I changed flock_t
to flock64_t, as we are all 64 bit now.  Also I added a lifetimer port,
which can be used by the server to request deadname notifications on.  The
idea is that the client creates one dummy port for all record locks, and if
the task dies, the dummy port is destroyed and the server can clean up all
the record locks that should now go away according to POSIX.

I don't really propose to actually apply this patch anytime soon.  I think I
would rather have a working implementation for some of the features first. 
But I also think that they are basically correct, and if there is any issue
that is in the way of this solution, I would like to hear about it.

One last note: I have not looked at what shared memory requires.  We said we
use the filesystem interfaces, but there might be one or two interfaces we
need to add.  I really don't know.  I will ponder this just to make sure I
am not solidifying something that will not work for shared memory.  If we
get the interfaces implemented, getting POSIX record file locking, shared
memory (and semaphores?) and proper linger behaviour is half there, which
means we really get the remaining important apps like GNOME (gconf),
Postgresql, Gimp, and such.

Thanks,
Marcus

Index: fs.defs
===================================================================
RCS file: /cvsroot/hurd/hurd/hurd/fs.defs,v
retrieving revision 1.50
diff -u -r1.50 fs.defs
--- fs.defs     13 Jun 2002 19:51:40 -0000      1.50
+++ fs.defs     18 Nov 2002 14:05:41 -0000
@@ -352,3 +352,12 @@
        RPT
        parent: mach_port_t;
        out new_file: mach_port_send_t);
+
+/* Apply, manipulate or query an advisory record lock.  If LIFETIMER
+   is destroyed, the lock is removed.  */
+routine file_record_lock (
+       lock_file: file_t;
+       RPT
+       cmd: int,
+       inout flock: flock64_t,
+       lifetimer: mach_port_send_t);
Index: io.defs
===================================================================
RCS file: /cvsroot/hurd/hurd/hurd/io.defs,v
retrieving revision 1.36
diff -u -r1.36 io.defs
--- io.defs     11 Jun 2002 21:37:16 -0000      1.36
+++ io.defs     18 Nov 2002 14:05:42 -0000
@@ -322,3 +322,31 @@
    on the specified object.  */
 routine io_revoke (
        io_object: io_t RPTLAST);
+
+/* Get a reidentified port to an io object.  The user should follow
+   this with a call to proc_user_identify.  The new_port passed
+   through the proc server will be a port usable with the new
+   identity.  */
+simpleroutine io_reidentify (
+       process: process_t;
+       RPT
+       rendezvous2: mach_port_send_t);
+
+/* Move a send right from the user to the server, which will
+   deallocate it.  The server might make some further synchronization
+   guarantees, depending on the type of the I/O object and the number
+   of extinct send rights.  Examples are:
+
+   * A pipe server might make sure this end of the pipe is properly
+   closed if the last send right was moved in the message.
+   * A socket server might linger before returning to the user if the
+   SO_LINGER option was active.
+   * A filesystem server might release the record lock by the caller
+   before returning.
+
+   Users that are not interested in such synchronization guarantees
+   can simply deallocate the send right.  */
+routine io_close (
+       io_object: io_r;
+       RPT
+       ioport: mach_port_poly_t);
Index: process.defs
===================================================================
RCS file: /cvsroot/hurd/hurd/hurd/process.defs,v
retrieving revision 1.28
diff -u -r1.28 process.defs
--- process.defs        21 May 2002 23:07:16 -0000      1.28
+++ process.defs        18 Nov 2002 14:05:43 -0000
@@ -364,3 +364,25 @@
        calling_process: process_t;
        target_process: pid_t;
        out tty: mach_port_send_t);
+
+/* Process identification.  */
+
+/* Called by a user in a reidentification transaction.  The rendezvous
+   port is used to match the request up with the server's
+   proc_server_identify call.  The newport is a port provided by
+   the server.  */
+routine proc_user_identify (
+       process: process_t;
+       rendezvous: mach_port_send_t;
+       out newport: mach_port_send_t);
+
+/* Called by a server in a reidentification transaction.  The
+   rendezvous port is used to match the request up with the user's
+   proc_user_identify call.  The newport is passed to the user
+   through the process server.  The identification information
+   is returned.  */
+routine proc_server_identify (
+       process: process_t;
+       rendezvous: mach_port_send_t;
+       newport: mach_port_poly_t;
+       out pid: pid_t);

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/