mrt@MRT.MACH.CS.CMU.EDU (Mary Thompson) (05/14/91)
Probably the best general overview of Mach is now the Chapter in Sliberschatz and Peters Operating Systems Concept book that Richward Ward refered to a couple of posts ago. In genreral, if one is talking about Mach 2.5 and there is not a specific Mach way of doing something, e.g I/O, then use the Unix (4.3 BSD) way. All the Unix kernel interface is supported so that Mach didn't have to rewrite something that was not central to its design. If you are talking about Mach 3.0 then it depends on what sort of servers you have running and what functions they support. At the moment most Mach 3.0 servers are still in the implementation or early testing phase. Mary Thompson, CMU
phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (05/14/91)
mrt@MRT.MACH.CS.CMU.EDU (Mary Thompson) writes: >central to its design. If you are talking about Mach 3.0 then it depends >on what sort of servers you have running and what functions they support. >At the moment most Mach 3.0 servers are still in the implementation or >early testing phase. Actually I was thinking both of 2.5 and 3.0. For 2.5 I was not sure how the BSD calls were actually implemented. I assume in 3.0, BSD calls would just be a library that exchanged messages on port(s) to the BSD server(s). What remains of an interest is how the servers themselves (which I assume even in 3.0 will run in their own tasks) do the actual I/O once requested from some other task. Obviously there would need to be some protection and/or assignment mechanism that the servers would take advantage of to get access to the I/O devices and yet prevent ordinary tasks from doing so. Where would server's binary code be "loaded" from, or would they really be linked in with the kernel, but just run as tasks? Where would I/O device drivers be? What I originally heard of MACH a few years ago suggested that it was a system that allowed a UNIX kernel to be written in a multitasking way. Seems like this will be so at least in 3.0. I had made some mental assumptions at the time, such as that MACH would be a different kind of thing than it really is. Particularly I suspected it might be a multitasking system that ran strictly in the real address space that enabled a conventional kernel to create the virtual address spaces with the advantage of a multitasking base to run on. Believe this I looked forward to the idea of device drivers getting access to the same benefit. I suppose I will be curious what is "under the hood" in MACH, and look forward to a more public 3.0 source availability. Particularly I am curious if there is an underlying multitasking system of sorts, such as perhaps one special "task" that represents the real address space, and multiple threads within it just as much as any task can have threads. Part of the curiosity is to compare with a small system I am designing and writing now. It does not have any virtual memory facilities at all, nor a file system, which should give you an idea how "low" it really is. -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/