gnu@hoptoad.UUCP (04/17/87)
In article <288@grebyn.COM> bob@grebyn.COM (Robert A. Baumann) writes: > The basic problem is that the thing is too closely tied to the > hardware. There's no good reason to bypass the BIOS for everything. > Due to this low-level implementation, you can't use any of the > thousands of DOS device drivers (like for my Bernoulli box, my custom > clock chip, etc). This discussion has brought out two points of view. One side says that Minix should build on the existing, working software for supporting odd devices. This side is right. The other side says that Minix is a multitasking system and can't use those drivers. It is almost right. The key is to realize that Minix can't run more than one task WHILE INSIDE THE BIOS DRIVERS. The rest of the time, it can. To get the best of both worlds, clearly you want to be able to bring up a binary copy of Minix on any clone or bozo, with any controllers, and have it work. It doesn't have to do context switches while waiting for disk I/O, or any other fancy stuff, but it should run and let you recompile the kernel, slowly. This could be done with a set of stub drivers which just call the BIOS and restrict the system from context switching (make it busy-wait for I/O completion) while BIOS I/O is in progress. Once the system is running, you can afford to be picky about execution speed (I can make Minix arbitrarily fast if it doesn't have to work!) and that's when you start trying the controller-specific, multitasking, interrupt driven, custom drivers. Note that you could run some I/O via the BIOS and some via specific drivers, e.g. the parts of your system that somebody has a working driver for, can run fast, and the rest can run slow until you write the Minix driver for it. It should also be possible to load in the MSDOS loadable device drivers and treat them like the BIOS drivers (no multitasking while in this driver). Stubs for the BIOS drivers should be used for the hard and floppy disks, keyboard, serial ports, and screen, until such time as the user goes to the work of selecting and installing the right (working!) Minix drivers. Maybe the timer too. The keyboard can be polled every timer tick to see if any chars have come in, so having the BIOS bufferring keystrokes is not a major problem. Sure, not running user programs while waiting for the serial port to clear is stupid -- but it's better than not being able to talk to the serial port, or the hard disk, which is the current situation! -- Copyright 1987 John Gilmore; you can redistribute only if your recipients can. (This is an effort to bend Stargate to work with Usenet, not against it.) {sun,ptsfa,lll-crg,ihnp4,ucbvax}!hoptoad!gnu gnu@ingres.berkeley.edu
stuart@bms-at.UUCP (Stuart D. Gathman) (04/20/87)
In article <1997@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes: > have it work. It doesn't have to do context switches while waiting for > disk I/O, or any other fancy stuff, but it should run and let you > recompile the kernel, slowly. This could be done with a set of stub > drivers which just call the BIOS and restrict the system from context > switching (make it busy-wait for I/O completion) while BIOS I/O is in > progress. We have a Motorola 6350 unix box that uses this approach. It has a diskette drive which is basically used only for software loading. Any access to the drive during normal operations shuts off interrupts while reading a diskette sector. This makes terminal I/O, disk I/O, proceed very slowly. (The system comes to a screeching halt.) The diskette does work, however, with what appears to be a minimum of software effort. -- Stuart D. Gathman <..!seismo!dgis!bms-at don'-eup