From owner-freebsd-hackers Tue Nov 18 03:03:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA13465 for hackers-outgoing; Tue, 18 Nov 1997 03:03:50 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA13459 for ; Tue, 18 Nov 1997 03:03:42 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id DAA25120; Tue, 18 Nov 1997 03:03:09 -0800 (PST) Message-ID: <19971118030308.27709@micron.mini.net> Date: Tue, 18 Nov 1997 03:03:08 -0800 From: Jonathan Mini To: Tony Overfield Cc: Jonathan Mini , hackers@freebsd.org Subject: Re: >64MB Reply-To: Jonathan Mini References: <3.0.3.32.19971110034509.0069e370@bugs.us.dell.com> <199711070205.MAA00455@word.smith.net.au> <3.0.3.32.19971110034509.0069e370@bugs.us.dell.com> <19971110022540.34863@micron.mini.net> <3.0.3.32.19971118044330.0071582c@bugs.us.dell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <3.0.3.32.19971118044330.0071582c@bugs.us.dell.com>; from Tony Overfield on Tue, Nov 18, 1997 at 04:43:30AM -0600 X-files: The Truth is Out There Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Tony Overfield stands accused of saying: [ ... snip ... ] > The nominal term "lowest 640K" is often used to refer to this real-mode > accessible user memory. In the context of this discussion, he could have > meant either the "lowest 640K" or the lower 64K of the second MB. I > guessed that he probably just dropped a zero from the 640K, when in fact > he was talking about the other. It makes no difference, the important > point was that the address needs to be real-mode compatible. Point taken, but I wanted to stress that any memory address readable from the classic 'real mode' addressing method is valid. > >(calculate the linear adress for > >FFFF:FFFF - it's (64K - 1) above 1M) > > "THat's not true." To be correct, you should have said "(64K - 16)." > Yes, that's picky, but I though you were being picky too. ;-) Ooops. :) Actually. If you want to be REALLY picky, it's (64K - 1) - 16, but hey... > >> If you can't trust the BIOS after the kernel is in memory, how can you > >> trust it to load the kernel into memory? While the kernel is still > >> "booting...", the BIOS should be safe enough to call in real-mode. > > > > The reason you can't trust the BIOS always is because once FreeBSD touches a > >device, the BIOS doesn't know it and might assume that the device is in a > >different state than it really is. The solution to this is to ensure that the > >BIOS and FreeBSD never touch the same devices. > > The only real way to ensure this is if FreeBSD doesn't touch devices, or > >the BIOS doesn't touch devices. > > Of course I can't fault the simple logic of this answer, but if you had > read my questions more carefully, you should have realized that I'm talking > strictly about the time _before_ FreeBSD touches the devices. In which case, my answer still stands : Until FreeBSD touches a device, the BIOS is a safe method of accessing it. > Once again, there's a certain time before the devices are touched and after > the bootloader jumps into the kernel where it would be advantageous to make > a few BIOS calls. I simply suggested doing so then, while it's still > easy to do and while it can't possibly conflict with anything that FreeBSD > has done up to that point. As an added bonus, when it is done at this > certain time, it doesn't increase space consumption by the bootloader, > which is a very important consideration. I agree -- In fact, I am a STRONG proponent of using the BIOS for various serives until the FreeBSD drivers can 'take over.' It makes sense for loading the kernel, it makes sense for a mutli-stage dynamically configured kernel (Something which I persoanlly need, and I know would be benificial to many other people as well), and it makes sense for a lot of other things, one example being the system console. If you ever want to see a cheap hack in the FreeBSD kernel, look to the system console code. It's a device, only it's probed and attached right off the bat, but only specific devices are probed there, which is defined by a C file rather than the kernel config. And to make things better, the device is probed and attached TWICE, rather than once. :) But wait! It gets BETTER! Not only does the kernel do a special probe/attach run for the system console, but it also creates a device major/minor for it! (look at /dev/cons :) ) But.. it's not a tty front-end for the kernel's entry point into the console, it's just a wrapper around the (assumed valid) tty interface from the console driver! (e.g. syscons) Which means that it doesn't have an independant tty struct. This is bad mana. The system console is an excellent example of how the BIOS services should be used to access a device before the FreeBSD device gets probed and attached in its proper order. If FreeBSD's special console code simply acted as a wrapper around the kernel's entry-point into the system console driver, and used the BIOS (or some code from the bootloader, to appease those of you who are now screaming 'but what about serial consoles?') for console I/O until the much-better-and-more-robust system console driver comes online. (Personally, I think that the system console behaviour should be layered, so as to remove a lot of these problems. Come on guys, the 'system console' is not ONE, but two or often THREE devices, and we need to treat it that way) > That's my last attempt. I apologize for not giving up sooner. > I simply can't tolerate the unusual level of effort that seems > to be required to be properly understood around here. I know the feeling... :( -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five."