Garry <asdfasdfasdfasd@adsfasdfasdf.com> wrote:
You can only get control on an open. Once the process manager has assigned
a connection between a client and a resource manager, no other resource manager
will be allowed to “interfere” (sample, sniff, look at, modify) with that
connection. The connection persists until closed.
What I get is that reads and writes to the disk work fine, although I
have not implemented my own io_read or io_writes. However, directory
Yes, the open has gone by you, been assigned to the appropriate resource
manager, and it’s the one that now handles them; so that’s why they appear
to work even though you haven’t written any code – you’re just not in the
loop.
Right, so if I implemented my own io_open, then reads and writes would
not work, unless I made them work myself?
Correct. Once an open() has been assigned to you, you are responsible
for all further communications with the client until the client does the
final close() [“Final” because there might be intervening dup()s and close()s]
reads like ‘ls’ do not work. So while my resmgr is running, I can do:
ls is trickier; I believe (but someone with current knowledge will have to
comment) that ls goes around and asks each resource manager for an opendir/readdir/close
cycle.
I don’t need to intercept opendirs or anything, is there a way to
explicitly exclude my resmgr from doing this?
Not sure if you can tell why you’re being open()d. If you can’t tell why,
then an open() looks just like an opendir().
The only way I can think of doing what you want is to take over everything
and have your resource manager call read() when its io_read() is called,
call write() when its io_write() is called etc. Effectively, you need to
intercept EACH AND EVERY function call because otherwise you have been bypassed
and you will not get the call that you are really interested in (the write()
or the close()).
Also, you’ll want to get in early and use the RESMGR_BEFORE flag to ensure that
you are first in line for requests…
I hope I have explained myself correctly…
I think I see now, intercepting each call might not be too bad, but can
I call the ‘original’ function after mine, or do I actually have to do
the work of the original function, the ‘original’ function being the one
that gets called if my resmgr is not running.
You are in a protected address space, meaning that you do not have access to
the “original” function – you must go through the API (e.g., open(), read(),
write(), lseek(), fpathconf(), chown(), chmod(), …) just like anybody else.
And, you also have to prevent yourself from open()ing yourself.
Consider if you took over /, and someone did an open of /home/garry/spud.txt.
You get the open(), and you say “I will handle this”. Not because you want to,
but because you want to get informed of changes. Since you’re handling it, you
now need to do an open() of /home/garry/spud.txt so that you can get the file
contents. But you don’t want to open() yourself [in fact, without setting a
special flag, you can’t]. So you need to reject the open() of yourself and
pass it on to the next guy. You could probably do this by looking at the
process ID of the person trying to open() you, see that it was yourself, and
deny the request.
Also, when you say “intercepting each call might not be too bad” you do realize
that you must COPY the data for each and every data transaction, right? So
if a process writes() to a file that you’ve intercepted, you must read the data
from the client, and write() it to the target yourself, doubling the amount of
data transfers.
Thanks a lot for the help.
Garry
No probs. Enjoy!
Cheers,
-RK
–
[If replying via email, you’ll need to click on the URL that’s emailed to you
afterwards to forward the email to me – spam filters and all that]
Robert Krten, PDP minicomputer collector http://www.parse.com/~museum/
