Date: Wed, 3 Jan 1996 11:52:10 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Cc: phk@critter.tfs.com, jkh@time.cdrom.com, obrien@cs.ucdavis.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: X for install Message-ID: <199601031852.LAA15173@phaeton.artisoft.com> In-Reply-To: <199601031506.HAA12239@freefall.freebsd.org> from "Justin T. Gibbs" at Jan 3, 96 07:06:41 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I thought the plan was to define a consistant probe "policy" for drivers > and have a "configuration manager" load lkms one by one to determine the > presence of hardware. I don't think we need to be in real mode for the > configuration manager part although having access to int13 and int15 > via vm86 would be really nice. (int15 is for EISA info). This is the problem I keep harping on memory object persistance about. You need a distinction between low persistance (probe code, etc.), medium persistance (buffer pool allocations), and high persistance (kernel and non-transient modules) memory objects to prevent serious fragmentation in an autoload process. You want an INT 13 VM86() disk driver to get the controller specific driver loaded (a medium persistance object, since you will want to discard it once it has done this). This is also a "fallback" driver, since it means you can use any disk DOS can use, if you have no native protected mode driver avilable. The INT 15 EISA problem is annoying, but I think you can use signature tagging to do memory size probing (the reason you need the EISA BIOS is that the per slot memory is not necessarily a fixed range and can vary from box to box, though most have pretty much standardized). 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?199601031852.LAA15173>