>>>>> "alexander" == Alexander Viro <viro@math.psu.edu> writes:
Hi
viro> What we need is a "I want rw access to fs"/"I give up rw access"/"make
viro> it ro" set of primitives. Unfortunately, it's even more compilcated -
viro> e.g. fs may stomp its foot and set MS_RDONLY in ->s_flags (e.g. upon
viro> finding an error if it has such policy). That DOESN'T look for files
viro> opened for write (reasonable) and DOESN'T revoke write access to them.
I really will like that thing for supermount, supermount tries to do
that thing by hand, and it really fails because it is difficult,
supermount tries to have the underlying fs unmounted if nobody has
open files on it, and mounted rw only when somebody has a file opened
on it and if someone has a file opened for write of there is happening
any operation that needs write access. As we don't have an easy way
to check if we are able to write in one filesystem (we can only use
the IS_RDONLY() macro), it happens that I have to mount the filesystem
rw for being able to call permission in that filesystem. Notice that
permission don't need write access per se, but the IS_RDONLY() macro
needs to have the filesystem mounted rw to fail. Yes, I can hack the
macro to do the things that I need, but that means that everybody that
needs that functionality will have to also hack it :(
viro> Again, the main issue here is what do we want, not how to implement it.
viro> Flame away.
I will want a method is the inode/super_block (don't care which of
them) for:
- is_read_only_fs()?
Notice that this method told as if we are able to have the
fs rw, not necessarily that the fs is rw at the moment.
- get_write_access()
- put_write_access()
Notice that there exist the functions get_write_access() and
put_write_access() functions in the tree, and I will be really happy if
there where a way to hook fs specific information there, as it will
make a lot of the code in supermount really easy, and the same for
other fs that need similar semantics.
Later, Juan.
-- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 07 2001 - 21:00:11 EST