Re: [PATCH] 2(3) hurd+glibc: Support for file record locking

2019-10-29 Thread Samuel Thibault 
Svante Signell, le mar. 29 oct. 2019 10:20:27 +0100, a ecrit:
> Maybe it did not hit me since I built and installed the patched
> hurd+glibc packages simultaneously?

Yes, that's why. Renumbering introduces incompatibility. If you upgrade
both at once you aren't hit.

The testsuite went fine, so I'll commit when I get the time to do it
properly, thanks!

Samuel

Re: [PATCH] 2(3) hurd+glibc: Support for file record locking

2019-10-29 Thread Svante Signell 
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 . 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!

Re: [PATCH] 2(3) hurd+glibc: Support for file record locking

2019-10-27 Thread Samuel Thibault 
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 . 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.

Samuel