Date: Mon, 16 Nov 1998 12:32:04 +0200 (SAT) From: Robert Nordier <rnordier@nordier.com> To: abial@nask.pl (Andrzej Bialecki) Cc: freebsd-current@FreeBSD.ORG Subject: Re: Probing devices in bootloader Message-ID: <199811161032.MAA00785@ceia.nordier.com> In-Reply-To: <Pine.BSF.4.02A.9811161011260.28991-100000@korin.warman.org.pl> from Andrzej Bialecki at "Nov 16, 98 10:31:17 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Andrzej Bialecki wrote:
> Hi all,
>
> I have a (possibly) interesting idea, and I'd like to share it with you.
>
> With the advent of the new booloader, I think it's possible now to do
> device probing from inside the bootloader. Let's suppose that each kernel
> module would have a special initialization section, which could be used in
> BTX environment. After all, most probing is just checking for the presence
> of some signatures at given locations, and this can easily be done in BTX
> environment, right?
Some probing is a fair bit more complex than this (see src/sys/isa/sio.c,
for example). Currently, BTX is not sophisticated enough to handle
various requirements (for instance, the interrupt flag is not virtualized;
and interrupts can't be disabled in ring 3).
Of course, this doesn't mean it couldn't be done, by enhancing BTX, if
we decided this was the route to take. BTX is currently constrained by
being needed both for the boot blocks and the boot loader. And the
boot blocks can't accommodate much more than BTX's present size of 1744
bytes.
So adding further capabilities to BTX would probably require two
separate versions. Conditional assembly, by means of #ifdefs or the m4
equivalent, doesn't usually work well for this kind of code; either
space efficiency is lost, or things become *extremely* messy.
Doing something roughly along these lines has already been been
discussed off the lists.
> Then, once the device has been successfuly probed, we could discard this
> section when loading it. This special init section would be probably of no
> use when running normal system, so that a kernel module would contain two
> of them - one for the normal operation, and one for the initial BTX
> enviroment.
A couple of reasons why this may not be a good idea:
o It would tend to introduce an architectural change along very
hardware-dependent lines (and the BTX environment is deliberately
very i386-specific).
o As far as debugging is concerned, BTX is fairly minimalist; and
can be tiresome to work in. It also requires more familiarity
with Intel CPU minutia than many developers have or even want.
> What this would buy us? IMHO, ability to check very early what devices are
> present, and to load appropriate modules only for them. It could be
> possible to build quite sophisticated multi-variant scenarios with
> alternative configurations based on the results of probing. It could also
> help to avoid memory fragmentation when loading/unloading modules, etc,
> etc..
>
> Now what\s your opinion on this? Especially those of you who nkow the
> workings of BTX, kernel modules, and the booting process much better than
> I do... :-)
I think it's an interesting possibility, and may be worth exploring.
In principle, one could even speed up the boot process (eg. SCSI_DELAY)
by doing certain things much earlier, and even in parallel.
--
Robert Nordier
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811161032.MAA00785>