Date: Tue, 18 Nov 1997 03:03:08 -0800 From: Jonathan Mini <j_mini@efn.org> To: Tony Overfield <tony@dell.com> Cc: Jonathan Mini <j_mini@efn.org>, hackers@freebsd.org Subject: Re: >64MB Message-ID: <19971118030308.27709@micron.mini.net> 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 References: <3.0.3.32.19971110034509.0069e370@bugs.us.dell.com> <Your <3.0.3.32.19971106150448.006d5438@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>
next in thread | previous in thread | raw e-mail | index | archive | help
Tony Overfield <tony@dell.com> 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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971118030308.27709>