Date: Thu, 4 Jan 1996 11:33:42 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, jdl@jdl.com, jkh@time.cdrom.com, obrien@cs.ucdavis.edu, freebsd-hackers@freebsd.org Subject: Re: X for install Message-ID: <199601041833.LAA18144@phaeton.artisoft.com> In-Reply-To: <199601040313.NAA09827@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jan 4, 96 01:43:14 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Well, this didn't *necessarily* need a VM86(). But that *is* one > > soloution... I was thinking on the lines of a weenie DOS program > > to blow the 32 bit offsets in the partition table before install. > > We need an awful lot more than that. While probing for disks and other > devices, we need a BIOS disk driver that can read the root filesystem > and suck in LKMs, including the disk drivers. Eventually, / would be > remounted from another device, and the now-loaded 'real' disk drivers > would come into play if they could, or the BIOS fallback driver would > continue to carry the load. OK. This belongs on the -arch list, but... This is my Top-20 wishlist for "FreeBSD: The Next Generation": 1) Ability to make BIOS calls from protected mode using V86 mode on the processor and return the results via a mapped interrupt IPC mechanism to the protected mode caller. 2) Drivers built into the kernel that use the BIOS call mechanism to allow them to be independent of the actual underlying hardware the same way that DOS is independent of the underlying hardware. This includes NetWork and ASPI drivers loaded in DOS prior to BSD being loaded by a DOS-based loader program, which means potential polling, which means DOS-not-busy interrupt generation for V86 machines by the protected mode kernel. 3) An image format that allows tagging of such drivers data and text areas in the default kernel executable so that that portion of the kernel address space may be recovered at a later time, after hardware specific protected mode drivers have been loaded and activated. This includes seperation of BIOS based drivers from each other, since it is better to run with a BIOS based driver in all cases than to not run at all. 4) Abstraction of the bus interface mechanism. Currently, PCMCIA, EISA, and PCI busses are assumed to be bridged from ISA. This is not something which should be assumed. 5) A configuration manager that knows about PNP events, including power management events, insertion, extraction, and bus (PNP ISA and PCMCIA bridging chips) vs. card level event management. 6) A topological sort mechanism for assigning reassignable addresses that do not collide with other reassignable and non-reassignable device space resource usage by fixed devices. 7) A registration based mechanism for hardware services registration. Specifically, a device centric registration mechanism for timer and sound and other system critical service providers. Consider Timer2 and Timer0 and speaker services as one example of a single monithic service provider. 8) A kernel exported symbol space in the kernel data space acessable by an LKM loader mechanism that does relocation and symbol space manipulation. The intent of this interface is to support the ability to demand load and unload kernel modules. 9) NetWare Server (protected mode ODI driver) loader and subservices to allow the use of ODI card drivers supplied with network cards. The same thing for NDIS drivers and NetWare SCSI drivers. 10) An "upgrade system" option that works on Linux boxes instead of just previous rev FreeBSD boxes. 11) Splitting of the console driver into abstraction layers, both to make it easier to port and to kill the X and ThinkPad and PS/2 mouse and LED and console switching and bouncing NumLock problems once and for all. 12) Other kernel emulation environments for other foreign drivers as opportunity permits. SCO and Solaris are good candidates, followed by UnixWare, etc. 13) Processor emulation environments for execution of foreign binaries. This is easier than it sounds if the system call interface doesn't change much. 14) Streams to allow the use of commercial streams drivers. 15) Kernel multithreading (requires kernel preemption). 16) Symmetric Multiprocessing with kernel preemption (requires kernel preemption). 17) A concerted effort at support for portable computers. This is somewhat handled by changing PCMCIA bridging rules and power management event handling. But there are things like detecting internal vs. external display and picking a different screen resoloution based on that fact, not spinning down the disk if the machine is in dock, and allowing dock-based cards to disappear without affecting the machines ability to boot (same issue for PCMCIA). 18) Reorganization of the source tree for multiple platform ports. 19) A "make world" that "makes the world" (rename the current one to "make regress" if that's all it is good for). 20) A 4M (preferrably smaller!) memory footprint. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601041833.LAA18144>