gnu-arch-users
[Top][All Lists]
Advanced

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

[Gnu-arch-users] Thoughts on VU


From: Matthew Dempsky
Subject: [Gnu-arch-users] Thoughts on VU
Date: 08 Jun 2004 23:21:37 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

vu sets the stage for some really neat and powerful ideas, but I think
we need a mechanism so that sub-processes can inherit the same handler
stack or something.

For example, if I write hash (Hackerlab shell) and it has code so I
can cd to /.../ssh/address@hidden/home/jivera, it will kinda suck
when I try to run any utilities on files in the directory because when
the shell forks and calls exec, the vu stack is reinitialized --
without the ssh vu vtable -- and fails.  (I think the issue of
non-vu-enabled tools failing is most likely unavoidable, but extra
points to anyone who can solve it.)

Since the code to implement all of the vu stack needs to be present in
both processes, all the handlers need to be in either hackerlab or in
shared libraries distributed with applications that are installed
somewhere and automatically loaded by hackerlab.  This seems like it
would add a lot of (potentially useless) complexity to each
processes's startup.

If we don't want that solution, we'll need either OS support (not
really portable) or an IPC-based vu handler that'll connect to *some*
process -- probably the parent process which would then need to add in
all the hair of handling asynchronous requests from children for
filesystem operations (and might even then need to pass requests to
its parent).  Yick.

Alternatively, we could write a vud (virtual unix daemon) which is
responsible for implementing a lot of vu requests and then have an
IPC-based vu handler that dispatches to it.  This would mean we only
need to worry about hairy asynchronous requests in one process.  We
can probably also use some environmental variables for specifying how
to connect to the daemon and what data to send to it.  Things like ssh
connections could then be tracked among children processes and when I
cd to /.../ssh/address@hidden/ in hash, I can still run all my
utilities without needing to enter my password again.  (Of course,
this opens a few security concerns that need to be carefully
addressed, but I expect nothing that any microkernel-based OS's
filesystem needs to handle.)

I imagine a more likely situation, however, would be to have multiple
vuds capable of different magic.  Then, the regexp handling in vu
would be used for deciding which vud to connect to and communicate
with.

How far off am I?

-jivera




reply via email to

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