On Sun, 2018-11-18 at 01:13 +0100, Samuel Thibault wrote: > Hello, > > 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 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.
Do you say that you are suddenly interested in the proposal I made in 2016? That proposal was completely dismissed by Justus by then! I don't even know if i have these modifications available somewhere, I've had several crashes with data losses since 2016.
