[comp.os.minix] source for open

dprrhb@inetg1.ARCO.COM (Reginald H. Beardsley) (05/07/91)

  Where is the source for the open() system call?  I have looked through fs,
mm, and kernel.  I found the code for DOING the work, but not the entry point.
From the structure of Minix this should be code to send a message to fs and 
then call the process scheduler.  It appears to be in libc.a but there is no
code for the current implementation in /usr/src/lib just source for a POSIX.1
compliant entry point.

   I have written code to do logical name translation for file and path names 
and want to test it using Minix.  If you wonder why I would want to do this 
I suggest that you work for a while with Motif and X11. (or for that matter 
try to put bcc someplace other than where Bruce put it.)

   The basic idea is as follows:

   Upon entry to open() check the path string against a table file in the 
user's home directory.  If a match is found change the path to the new string
produced by string substitution.  Next check a system translation table in 
/etc and substitute again.  This allows full revectoring of any file or 
directory without requiring write access outside the user's own space.
Effectively, it provides private symbolic links.

   I also would like any comments about possible problems with the idea.
There are, of course, some complications that will result for things like
ls, which, etc, which still need to be resolved.  I plan to go look at 
how VMS handles this to see what to do about that. Thanks all.

-- 
Reginald H. Beardsley       
ARCO Information Services
Plano, TX 75075           
Phone: (214)-754-6785
Internet: dprrhb@arco.com 

HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (05/08/91)

of course, this code is in the libraries! try ..../lib/posix/open.c

C.v.W>

dprrhb@inetg1.ARCO.COM (Reginald H. Beardsley) (05/09/91)

Thanks for the responses.  I find I was not clear about what I'm up to.

My concern is not with a specific executable with hard paths, but rather 
the more general problem of testing software on a production machine where
it is necessary to have two copies of the same code which the user is able
then to select his choice at run time.  This is SOP in large shops running VMS
or MVS.  If people wrote their code for the Unix environment using 
environment variables to set paths, this wouldn't be such a problem.
Unfortunately, too many people have emulated the sins of the Unix source
code.(cf. the articles on BSD-386 by Jolitz in Dr. Dobb's).

Unix was designed as a research tool, not as a production OS.  It meets its
design goals extremely well.  The rapid pace of hardware development has
led to our using Unix for many things for which it was not designed.

Because I have the source for Minix and a cheap machine to run it on I can experiment with possible fixes for some of these.  They won't let me take over the Cray to test a recompiled kernel with Reg's patches.  Since I don't want to have to support the OS all by myself, I wouldn't patch it even if they were to let me.

The traditional Unix solution of symbolic links is unsatisfactory for two reasons.  First, it requires write access someplace the user should not have it. Second, it is global and effects all users of the system, thus failing 
my requirement to run both test and production code on the same system at the 
same time.

Andy may have written Minix for the purpose of teaching operating systems 
design and implementation, but I'm sure I'm not the only one who finds it 
very useful for many other things.  I'm still spending most of my time 
patching code and learning about the OS, but I'm also outlining some serious 
work which will use Minix as the test bed. 

PS:  There are some potentially serious security implications for the 
basic idea of revectoring hard paths through a table.  What about a user
substituting his own version of /etc/passwd?

-- 
Reginald H. Beardsley       
ARCO Information Services
Plano, TX 75075           
Phone: (214)-754-6785
Internet: dprrhb@arco.com 

tim@proton.amd.com (Tim Olson) (05/09/91)

In article <1991May7.140448.10727@Arco.COM> dprrhb@inetg1.ARCO.COM (Reginald H. Beardsley) writes:
| 
|   Where is the source for the open() system call?  I have looked through fs,
| mm, and kernel.  I found the code for DOING the work, but not the entry point.
| From the structure of Minix this should be code to send a message to fs and 
| then call the process scheduler.  It appears to be in libc.a but there is no
| code for the current implementation in /usr/src/lib just source for a POSIX.1
| compliant entry point.

If you are using version 1.5 on the IBM PC, then the sequence is:

	open()	  in lib/posix/open.c	calls
	callm1()  in lib/other/call.c,  which calls
	sendrec() in lib/ibm/sendrec.s,   which performs an
	int SYSVEC instruction.


--
	-- Tim Olson
	Advanced Micro Devices
	(tim@amd.com)