NotesAboutKeithsDeviceDriverDesign.Imported @ jos.sf.net

Let me know what you think! - KeithMason

Ok. Let's do that. Your design looks promising so far... My main question so far is: Why do you want to use RMI? Where do you see the advantages etc. ? Furthermore it seems that you made the assumption that JOS will run multiple VMs instead of just running one VM and seperating "processes" in other ways. Again the same question: Why do you assume this? Where do you see the advantages? MarkusPeter - 17-Mar-1998

I don't know if it's as much an assumption as it is not much of a distinction. For this to be a real operating system, we are going to have to support the concept of multiple address spaces (at least optionally; maybe an embedded system wouldn't want or couldn't use this feature).*

The way I see it in my head, there is an area in every address space that the Java runtime and data structures reside. The Java runtime code, like a shared library or the kernel image in a UNIX system, is shared between address spaces. Likewise, some of the data must be shared (local socket memory would be one example). But some data must be local to the address space for security reasons. So whether you see one Java VM controlling multiple address spaces or one Java VM per address space is a matter of perspective.

The advantage of RMI is its generic approach to communication between objects that are not local to each other. Let's say that you have a program that is optimizing files on a hard drive (like Norton Utilities' speed disk [I choose this example instead of, say a word processor, because of the wider variation of what it does]). The program is started up locally on the computer by the user. It reads in the table of contents directly from the instance of the disk object it is optimizing. It goes about its work reading blocks, writing blocks, etc. Now let's say that the user backgrounds the optimizer and starts running a spreadsheet which performs some CPU intensive operations. The Scheduler class (as yet undefined in my design) in contact with other Schedulers on trusted computers, determines that some free time is available on another computer, and schedules the optimizer to run there.

The Schedulers on the two computers cooperate and the task object (owning an address space object) is send across using RMI. The memory objects are also owned by the computer that owns the task, so as the code is executing and page faults occur, the byte streams that the pages consist of are forwarded across automatically by RMI. Also, as the program executes, block reads and writes to the disk still occur to the original disk instance; however, the data for the blocks are not passed across the network: only the memory reference objects. When reading, memory local to the computer the disk instance stores the block; an RMI proxy is returned to the program; the program sends a write command with the memory object; and the data is written to the disk. Very little network traffic occurs here (maybe 20-60K to page-fault the code and data, and 200 bytes or so for each read/write).

So in this way, RMI can provide the framework for true transparent (and optional) network clustering with almost no thought to the programmer or end-user.

-- KeithMason 17-Mar-1998

* I have looked at a few more places on this site, and realized that address spaces aren't even a consideration yet. However, I'd like to make a couple of points.

1) Multiple address spaces will be needed eventually. For one, 4 Gigs of an address space is going to be insufficient soon. Also, it allows for easier security breaches. Further, without it, you are limited to a single user OS.

2) Designing with address spaces in mind doesn't mean that thay have to be implemented even in the first few years. All it will allow is ease of transition when the feature is implemented.

3) In a single Java VM, RMI is moot. If you design to use it, and you never leave the local VM, not harm is done. RMI will never be invoked. But as soon as you go multi-VM or across the network, it being there will ease many things emmensly (as well as complicate a couple low level things such as scheduling). But the end-user would never see the transition.

-- KeithMason 17-Mar-1998

I like your RMI idea and support it whole-heartadly (I think it should be called something other than RMI if it's going to be used locally)

As for the multiple VM discussion, I look to DOS and see how it handles the situation. The VM's could work like command.com in the way it can load once at start up, run programs init one at a time or threaded, but sepreate instances of it can be created; which will be handy when JOS moves from CLI to GUI. I think alot of the Process handling can be handled in the SecurityManager and the System classes.

--DigiGod

Check out the discussion on drivers on the kernel mailing list or in the archive http://www.spin.de/osproject/archive/jos-kernel-archive/date.html.

-- RobertFitzsimons (19 March 1998)

I was thinking similar plans recently. Many of the interfaces between applications and operating system should be RMI ready - that is: they should be remote interfaces and they should throw a remote exception. For local implementation, there is NO overhead - there will be NO RMI at all. At the same time, all applications will be network ready.

However, I think RMI should not be done at the lower levels - RMI ready file API is good. RMI ready driver is a bit too inefficient. If you want to do remote low level access, you can always wrap another interface above the driver level.

-- DivakarShekhar (22 March 1998)

Content of these pages are owned and copyrighted by the poster.
Hosted by: