bonfire@jetsun.WEITEK.COM (bonfire software) (04/07/89)
I have been making my way through vol 1 of Doug Comers' book for the macintosh, and I was thinking of trying it out. Do I understand from the book that, as it stands, xinu cannot be booted, move through the file system, and run programs ? The text suggests that this is not so when it talks of running application programs by loading them along with xinu. Is this correct ? It would seem to be a severe limitation even taking that xinu is presumably meant as an educational tool. John Mcleod (weitek!johnm)
sbm@CS.PURDUE.EDU (04/07/89)
John Mcleod asked whether it is possible for Xinu to load programs
dynamically from a file and run them.
The Xinu operating system actually consists of a library of system
calls and a main program that boots the system and runs the user's
program as a process, all of which are loaded with the user's program
before run time. Xinu creates processes running functions that are
already loaded, rather than reading them in from disk; thus, it is
possible for Xinu to run on a machine without a file system (as it often
does in practice). Modifying Xinu to load processes dynamically from
disk is of limited utility, since Xinu does not have a compiler, and so
you have to leave Xinu to compile a program anyway. Furthermore, Xinu
will never be able to run arbitrary Macintosh applications, since these
use Macintosh ROM traps instead of Xinu system calls. In the spirit of
Xinu, though, I have to say that it would be an interesting exercise to
implement dynamically loaded processes in Xinu. In a nutshell, here is
what it would involve.
The user would compile and link dynamically loaded executable files
separately from the Xinu operating system itself. Since none of the
addresses of Xinu system calls are available when compiling and linking
these files, the Xinu system calls would have to be implemented as
traps, rather than as function calls, as they currently are. Then
creating a dynamic process would require allocating space for the code
and static data (text, data, and bss segments) in the heap using getmem,
reading the file in, relocating the addresses in the newly read code and
data, and creating a Xinu process whose program counter points to the
entry point of the new code. The 68000 architecture of the Macintosh
makes this job a little easier, since it uses PC-relative code addresses
which are independent of the location of the code in memory. Hence,
only static data addresses (addresses of data not contained in the
stack) would have to be relocated. It would be nice to release the
memory the process occupies when it dies, but the process might create
other processes running parts of its code or using its static data, so
the heap memory would have to remain allocated after process exit.
I wish I had more time to play with ideas like this. Have fun.
Steve Munson
sbm@Purdue.EDU
sbm@Purdue.CSNET
----------rjh@cs.purdue.EDU (Bob Hathaway) (04/08/89)
In article <8904071506.AA03015@merlin.cs.purdue.edu>, sbm@CS.PURDUE.EDU writes: > John Mcleod asked whether it is possible for Xinu to load programs >dynamically from a file and run them. > > The Xinu operating system actually consists of a library of system >calls and a main program that boots the system and runs the user's >program as a process, all of which are loaded with the user's program >before run time. Xinu creates processes running functions that are >already loaded, rather than reading them in from disk; thus, it is >possible for Xinu to run on a machine without a file system (as it often >does in practice). Modifying Xinu to load processes dynamically from >disk is of limited utility, since Xinu does not have a compiler, and so >you have to leave Xinu to compile a program anyway. Furthermore, Xinu Yes, but executable files wouldn't need to be linked with the xinu operating system reducing static linking time by about 30 to 40 seconds on a Sun 3/50. Also, it would be nice to execute utility or any executable programs as they exist in the file system from a shell without rebooting and reloading the kernel operating system. In a graduate-level distributed systems class at Purdue, I proposed dynamically loaded heavyweight user-level processes, as originally suggested to me by Jim Griffioen, for the preceding reasons. Xinu's purpose was primarily for real-time systems such as file and page servers or for educational purposes in several courses at Purdue and elsewhere. The proposal entailed a process model supporting threads running in (dynamic) heavyweight processes which was modified and subsequently accepted in class. An interesting feature emerged from allowing heavyweight processes. Since the Xinu OS interface provides concurrent system calls for lightweight processes, it became obvious that separately compiled xinu programs should be allowed to run multiple threads of control per process which lead to a new process table implementation based on address spaces. This makes Xinu an excellent vehicle for an Ada virtual machine because Ada tasks could be trivially implemented as Xinu threads. This is a project which may become feasible in the near future. > The user would compile and link dynamically loaded executable files >separately from the Xinu operating system itself. Since none of the >addresses of Xinu system calls are available when compiling and linking >these files, the Xinu system calls would have to be implemented as >traps, rather than as function calls, as they currently are. Then I also worked on system calls and library routines in the aforementioned class and we did provide a library and trap mechanism to support user level (dynamic) processes. Dr. Comer's PhD students are still working on the system. Bob Hathaway Rjh@purdue.edu