[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] 2(3) hurd+glibc: Support for file record locking
From: |
Svante Signell |
Subject: |
Re: [PATCH] 2(3) hurd+glibc: Support for file record locking |
Date: |
Tue, 29 Oct 2019 10:20:27 +0100 |
User-agent: |
Evolution 3.34.0-2 |
On Sun, 2019-10-27 at 21:06 +0100, Samuel Thibault wrote:
> Svante Signell, le jeu. 12 sept. 2019 10:23:55 +0200, a ecrit:
> > @@ -358,6 +357,18 @@ routine file_reparent (
> > skip; /* Was: file_get_children. */
> > skip; /* Was: file_get_source. */
> >
> > +
> > +/* 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>. RENDEZVOUS is MACH_PORT_NULL for per opened
> > + file locking and !MACH_PORT_NULL for per process file locking */
> > +routine file_record_lock (
> > + file: file_t;
> > + RPT
> > + cmd: int;
> > + inout flock64: flock_t;
> > + rendezvous: mach_port_send_t);
> > +
> > /* Overlay a task with a file. Necessary initialization,
> > including authentication changes associated with set[ug]id
> > execution must be handled by the filesystem. Filesystems normally
> > implement this by
>
> I'm only realizing this, now that I see that rebooting with the
> patches applied on hurd fails completely: never insert an RPC between
> existing ones! That renumbers everything, we do not want that at any
> rate. I'll fix that along committing.
Thank you Samuel for finding time to review the patches. Regarding the
placement of file_record_lock in fs.defs I have not changed it. That
place was selected by Neal in 2001. Of course a lot has happened since
then. Sorry for not realising that it should be placed in time order,
but I never had a failing boot due to this error. Maybe it did not hit
me since I built and installed the patched hurd+glibc packages
simultaneously?
Thanks!