[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: [PATCH hurd 3/6] Add file record locking support: libtrivfs_fil

From: Samuel Thibault
Subject: Re: RFC: [PATCH hurd 3/6] Add file record locking support: libtrivfs_file_record_lock.patch
Date: Sun, 18 Nov 2018 01:13:38 +0100
User-agent: NeoMutt/20170113 (1.7.2)


Triggered by an IRC discussion, I had a look at this old mail still in
my mbox:

Justus Winter, le lun. 08 févr. 2016 15:04:14 +0100, a ecrit:
> Quoting Svante Signell (2016-02-08 14:44:09)
> > Where to find the code setting the underlying node of the null translator 
> > flags
> > to zero?
> It starts with /dev/null having a passive translator record.  If that
> is first accessed, diskfs_S_dir_lookup will start the translator on
> demand.  Somewhere between diskfs_S_dir_lookup, fshelp_fetch_root,
> fshelp_start_translator_long, there is a callback that opens the
> underlying node.

More precisely, it's trivfs_startup which calls fsys_startup to get the
underlying node. It's just passing its flags parameter, which happens to
be 0 in basically all translators, except the term translator in some
case. I don't really know why, except probably potential for spurious
side effects.

Quoting Svante Signell (2016-02-08 12:53:56)
> - I have a working solution, which adds two new structs to struct 
> trivfs_peropen
>   struct rlock_peropen lock_status;
>   struct trivfs_node *tp;
> This solution was not accepted

I don't remember the discussion which refused this solution. I guess
your working solution is to implement the record-lock in trivfs
itself? It sort of makes sense to me actually: the data of the
underlying node and the data of the node exposed by the translator
are not really related, I don't see why we should necessarily proxy
the lock. Apparently the only parts which are proxied are file access
permissions and time, i.e. information of the inode itself.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]