|
|
1.1 root 1: I am pleased to announce the availability of an initial development
2: snapshot of a new variant of the Mach kernel, which I am tentatively
3: calling OSKit-Mach. The starting point for this variant is the current GNU
4: development version of Mach (aka GNUmach). The difference between GNUmach
5: and OSKit-Mach is that I have entirely ripped out all the old Mach and
6: Linux device driver code and several parts of the i386 hardware support
7: code and replaced them with uses of the OSKit's hardware support and device
8: driver libraries.
9:
10: Please note that although I am a sometime employee of the University of
11: Utah's Flux Group (makers of the OSKit), and I am a Hurd developer and a
12: long-time volunteer and former employee of the GNU Project, this is wholly
13: a personal project of mine that I began on my own without consulting
14: anyone. I am using the Hurd project's CVS repository for OSKit-Mach
15: because it is convenient for me (seeing as it's a branch off the current
16: gnumach development) and is a convenient way for me to make my code
17: available, and obviously I am encouraging use of the University of Utah's
18: OSKit, but that should not be misconstrued as an endorsement of my project
19: by the Hurd project, the GNU Project, the FSF, the University of Utah, or
20: Major League Baseball. I just decided this would be a fun thing to do.
21:
22: For the time being, this is most definitely for kernel hackers and
23: dedicated "thrill seekers" only. If anything or everything in this message
24: makes no sense to you, then please just don't worry about it. Just wait,
25: and people to whom it does make sense will decide if and when you want to
26: worry about it and give you specific instructions on where to go and what
27: to do at that time.
28:
29: This variant is intended to be completely identical to GNUmach from the
30: user-mode perspective (aside from the behavior of the device drivers), and
31: I intend to keep Oskit-Mach abreast of all applicable changes to GNUmach on
32: a regular basis (not much is changed from GNUmach aside from the drivers).
33:
34:
35: In some respects this project brings the relationship of Mach and the OSKit
36: full circle. When maintenance of Mach 3.0 at CMU waned, the University of
37: Utah's Flux Group took over in the form of the Mach4 project, and revamped
38: much of the i386 machine support code in the course of their research.
39: While at Columbia University, Shantanu Goel worked on using Linux device
40: drivers in Mach, and later continued this work at the University of Utah.
41: Utah Mach4 became the seat of Mach development on the 3.0-compatible line,
42: and the microkernel underyling the GNU/Hurd multiserver operating system.
43: When the Flux Group's research moved on from Mach to other systems, they
44: wanted to reuse the work they had done in hardware support and device
45: drivers; this work (and a whole lot more) eventually evolved into the
46: OSKit. Meanwhile, when the Flux Group stopped maintaining Mach4, the Free
47: Software Foundation's GNU Hurd Project had taken it up and produced the
48: GNUmach release to go with the Hurd. Since then, the Hurd has become an
49: all-volunteer project whose developers are not paid by the FSF, and later
50: GNUmach releases incorporating bug fixes and updating the Goel/Utah
51: encapsulation of Linux device drivers have been made by volunteers
52: including Okuji Yoshinori and Thomas Bushnell.
53:
54: This bit of history explains some of why it was so easy to replace a lot of
55: the GNUmach/Mach4 hardware support code with OSKit calls--in many cases the
56: OSKit code is a direct evolution of the code originally in Mach4 that I was
57: replacing, with the names changed and improvements Utah has made since the
58: Mach4 days.
59:
60:
61: * What you get vs GNUmach
62:
63: ** All the benefits of an OSKit kernel
64: -> Device drivers from Linux 2.2.12 (IDE, SCSI, and Ethernet)
65: (GNUmach has Linux 2.0.36 drivers with a few fixes.)
66: -> Serial-port console support with a very simple minimal serial driver
67: -> OSKit-style Multiboot support, including "return address" hack
68: for extra-speedy soft reboot when using OSKit's Netboot
69: -> Serial-port GDB support for debugging the microkernel in style
70: -> The University of Utah might maintain the device drivers for you
71:
72: ** A much smaller source tree! The unpacked OSKit-Mach sources total about
73: a quarter of the GNUmach sources (though the OSKit itself is much larger
74: of course). The gzip'd tar file of the source tree is about 700k, vs
75: 3.6MB for gnumach. This is because I have wiped out much old cruft, as
76: well as all the old device drivers and the Linux code.
77:
78:
79: * What you lose vs GNUmach
80:
81: ** All the old device drivers are gone, so you only get what the OSKit has.
82: It would not be very hard to support some of the old drivers alongside
83: the OSKit drivers, but I am not interested in working on that. I am
84: more interested in adding good new drivers to the OSKit.
85: *** The PC screen/keyboard console driver is very minimal, and not
86: compatible with the old Mach driver's terminal emulation.
87: The OSKit's PC console emulates an adm3a terminal, and the keyboard
88: input support is very simple.
89: *** No real serial drivers at all
90: The serial drivers that provide the serial console and serial GDB
91: are very minimal and not really generally usable serial drivers at all.
92: The oskit's freebsd serial driver might work, but the interface glue
93: for features specific to serial ports (baud rate, modem control, etc)
94: is not there.
95: *** No parallel (printer) port driver(?)
96: The oskit's freebsd printer driver might work.
97: *** No real drivers for PC keyboard or PS/2 mouse at all.
98: The oskit needs a good clean driver for the low-level keyboard access.
99:
100: ** No DDB. I ripped it out rather than making it work. Serial GDB is much
101: better. It might be useful at some point to resurrect some of DDB's
102: code that prints out kernel data structures in comprehensible form.
103:
104: * What the hell is the OSKit again?
105:
106: See <URL:http://www.cs.utah.edu/flux/oskit> to learn all about the OSKit.
107: Please don't ask me to tell you all about it, because I won't do it.
108:
109: * Where to get it
110:
111: The source is in the Hurd project's CVS repository as a branch of gnumach.
112: This is available for anonymous CVS from the GNU Project's server.
113: See <URL:http://www.gnu.org/software/devel> about using anonymous CVS.
114: You want to check out the gnumach module with the tag `oskit-branch', i.e.:
115:
116: cvs -d :pserver:[email protected]:/gd/gnu/anoncvsroot co -d oskit-mach -r oskit-branch -P gnumach
117:
118: I don't expect to do much in the way of distributing this other than by
119: anonymous CVS any time soon, until it is ready for some kind of release.
120: As I said, at this stage this is for seasoned kernel hackers and masochists
121: only, so I will presume anonymous CVS is something you can cope with.
122: Since cvs is a bit of a bear for the first checkout, I've put together a
123: tar file containing a checkout from anonymous CVS (complete with CVS
124: directories) to get you started. You can find it at
125: <URL:ftp://ftp.ai.mit.edu/pub/users/roland/mach/oskit-mach-19991125.tar.gz>.
126:
127:
128: * What you need to build OSKit-Mach
129:
130: The build is just the same as GNUmach, except that first you will need to
131: build and install the OSKit. You need the 19991124 "Butterball" snapshot
132: release of the OSKit, which is at
133: <URL:ftp://flux.cs.utah.edu/flux/oskit/oskit-19991124.tar.gz> (or a later
134: version). See <URL:http://www.cs.utah.edu/flux/oskit> for more information
135: about the OSKit, including its mailing list and archives (where that
136: wildman Okuji had already posted fixes before the sun set on that
137: snapshot's first day!).
138:
139: Please don't ask me about building the OSKit; see the web site and the
140: documentation included with the source about what to do and to whom to
141: complain. (And realize that this is an informal bleeding-edge snapshot,
142: not a released OSKit version, so you should expect to try to figure out
143: your own problems.) Before you try to build OSKit-Mach, please test your
144: OSKit build on your hardware by building and running some of the oskit's
145: example programs and making sure they boot and run ok.
146:
147: The only way that I've actually built oskit-mach is with my i486-gnu (Hurd)
148: cross-compilation setup; I just built the oskit with that cross-compiler
149: and --prefix=/usr/i486-gnu and installed it. Then just configure
150: oskit-mach normally and build. All of this should work with any native
151: ELF/x86 compiler too (and no --prefix). It should probably work to
152: configure oskit-mach using the oskit's compiler front-end (i386-oskit-gcc),
153: but I haven't tried that and don't recommend it. The only difference
154: between using a native compiler or a cross-compilation setup that has glibc
155: installed, and using i386-oskit-gcc, should be that a few functions such as
156: memcpy will come from the oskit's minimal C library rather than from glibc,
157: which has much better-optimized implementations of those
158: performance-critical functions.
159:
160:
161: * If you are a rabid Mach kernel hacker
162:
163: There are a few things to mention about technical details of how I did some
164: things, and I will write some notes up sometime soon and stick them in the
165: sources someplace. In the meantime, there are some comments and if you
166: grok the kernel already then reading the code should be substantially
167: self-explanatory. Aside from removed files, the diffs between the gnumach
168: trunk and the oskit-branch are fairly small (cvs is your friend); all the
169: new oskit-related support code is in the new oskit/ subdirectory.
170:
171:
172: Please send bug reports to <[email protected]>. If you have a problem with
173: device drivers, before you report it to me as a problem with OSKit-Mach,
174: please try those drivers on your hardware using some oskit example kernels.
175: If your problems show up using those device drivers on your hardware in an
176: oskit example kernel, then please report it to <[email protected]> as
177: an oskit problem rather than reporting it as Mach problem.
178:
179:
180: Enjoy,
181: Roland McGrath <[email protected]>
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.