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 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. Samuel
