From owner-freebsd-hackers Sat Sep 30 15:09:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA20352 for hackers-outgoing; Sat, 30 Sep 1995 15:09:20 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA20345 for ; Sat, 30 Sep 1995 15:09:18 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA18818; Sat, 30 Sep 1995 15:03:56 -0700 From: Terry Lambert Message-Id: <199509302203.PAA18818@phaeton.artisoft.com> Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. To: glen@winternet.com (Glen Overby) Date: Sat, 30 Sep 1995 15:03:56 -0700 (MST) Cc: hackers@freefall.freebsd.org In-Reply-To: <199509301911.OAA00320@subzero> from "Glen Overby" at Sep 30, 95 02:11:27 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3854 Sender: owner-hackers@FreeBSD.org Precedence: bulk > >We really need to get the dynamic device driver issue > > on the road if we're to ever have any hope at all in running on > > small memory machines for the forseeable future. Perhaps one > > Let's hold on to this thought for a moment: what is preventing this > from happening *today*? For the moment, forget the additional > problems of doing this in the installation process. 1) There is adamant opposition to a symbol resolution facility in the kernel itself. 2) Without a symbol resoloution facility in the kernel itself, there is no way to cause demand loading short of a fully running system causing a daemon to do the loading. 3) Symbol resoloution implies that the exported kernel interfaces must have symbol information available to the resolver. Actually, I see no reason why kernel level file I/O can not be used to get this information from the kernel file, though keeping in the kernel itself will accomplish two worth goals: a) It will be faster b) It will be possible to limit the exported interfaces to less than the full list of kernel symbols, making less risky to make large scal kernel changes by reducing the exposed entry points. Typically, I believe that one of the largest exposures is in disk and CD ROM drivers. The disk interface lends itself to a "fallback" BIOS-based interface for initial load, to be followed by demand-loading of controller specific drivers. This facility would greatly reduce kernel size, but would require that the VM86() interface be expanded sufficiently to support BIOS-based single-threaded disk drivers to allow loading up to the point of loading the protected mode drivers via the VM86 int21 and/or int13 interfaces. The cdrom facility is problematic, since CDROMs do not typically hook a defined interface at POST time. Therefore, there must be static kernels available for CDROM loading, or a DOS-based facility for assembling a non-CDROM boot disk with apropriate loadable drivers on an FDC file system (the FDC *must* remain statically there, unless it, too, is accessed via BIOS). This second option would mean that a 4M "bootable" CDROM was not a possibility. Because of the inability to mount MFS over static configuration areas, both because of the configuration architecture itself and the lack of fully functional file system interfaces for doing this, a bootable CDROM is not currently an option in any case (unless it does not support net operation at all). The operation of the demand loading facility requires the ability to load-probe-unload to keep the kernel size small. This in general has the effect of implying that the kernel lives in a virtual map, and that one can logically seperate by zone the driver load location from the physical load address. This makes it easy to discard a driver, or even cause the kernel to accept page faults to get the driver in for media which is non-system critical. The resolves the issue of needing to do a load of probe code seperate from the driver code itself. Further, using segment designation, the probe code and possibly the attach code can be discarded after use (depending on how seriously one want to take the idea of plug-n-play device dynamic configuration -- ie: PCMCIA cards). Similarly, the detach routine may in fact be left unloaded until such time as it is needed, assuming segment designation in the object format. In short, it is possible to do, but how much effort would be required is dependent on how agressively the issues are to be attacked. I'd like to see some mechanism for kernel virtual address space zone designation and kernel page fault handling, as well as more VM86() work before the idea demand loading is taken very seriously. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.