Hello Jiri,
here are a few of my comments to your VFS proposal. In general, I
consider your proposal reasonable and interesting. I am really looking
forward to some initial prototype.
1. A task can have its own private “view” of all the resources it accesses via
VFS.
b. Hurd and Plan9 made some steps towards creating customized namespaces for
processes, though the basic usage pattern matches that of legacy systems.
This is an important observation: Many systems already have some support
for file system namespaces (even plain Linux kernel supports them on a
very basic level -- there is still one global file system hierarchy, but
different processes can have different views on the tree). But they are
used only rarely in practice. The only prominent use I can think of is
for the purposes of single-kernel virtualization (containers).
Therefore the crucial point here is not only to implement the namespace
mechanisms, but more importantly to design the usage patterns and
policies for such mechanisms and wrap them in convenient run-time services.
My personal experience is that per-file permissions are non-obvious, easy to
get wrong and also a complete mess when sharing files among systems with
different sets of users. Protection based on location accessibility is natural
for humans (if you want some thing inaccessible, you put it in an inaccessible
place; putting a sticker with your name on it won’t stop thieves, thick steel
door usually will).
This is also an interesting idea, related to the capability-based
systems (as already mentioned in this thread).
Again, my concern here would be very practical: Traditional i-node
permissions make it easy to persistently store the complete effective
permission set of a file system (and recreate it in memory when
accessing the file system). The problem of sharing files among systems
can be solved by not using local identifiers of subjects (e.g. users),
but by using globally unique identifiers.
I am not saying that the problem of persistent storage and recreation of
the effective permission set cannot be solved in capability-based
systems. I am just saying that you should perhaps elaborate on it, too,
because the solution needs to be designed properly (both on the level of
mechanisms and on the level of policies).
Their addressing uses a notation similar to that of Plan9 (where it only covers
device namespaces); paths start with the ‘#’ symbol
I know that you striked-through this part, but I would still like to
propose an alternative. My idea of how one might address the imported
trees is based on URLs. I.e. an imported tree can be addressed using an
URL scheme in a form of:
namespace://<namespace>/<path>
Of course, the primary tree might be addressed using the traditional
(and implicit) URL scheme:
file://<path>
Designing the addressing mechanism around URLs might be quite
beneficial, because it allows to extend the addressing naturally to
other local and remote resources (local location service nodes, remote
network file systems, HTTP, you name it).
M.D.
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
