In message <199512172242.RAA07651@jekyll.piermont.com>, "Perry E. Metzger" writes:
> 
> I've created a new function in arch/i386/boot/bios.S called usleep
> that does what you would expect, and I'm altering gets in io.c to use
> it to insert 50ms delays instead of relying on ischar().

Thank you!  I hope this gets put in... ;-)


> My questions to the studio audiance:
> 
> 3) The boot software has a number of cosmetic uglynesses.

Hah!  Yup!  ;-)


>    a) The boot software is very confusingly named. There is all sorts
>       of obsolete stuff created. Why do we still have fdboot, sdboot
>       and wdboot when they are all the same? Can anyone think of a
>       better name for the two parts than *boot and boot*
>       (i.e. bootbios and biosboot), which is damn confusing to any
>       sane person? Should these just be named boot1 and boot2 to
>       correspond with whats listed in README.386BSD

Yeah, it's confusin'...  but that's the way it is...  ;-)


>    b) The boot software is very poorly documented. Stuff like
>       README.MACH, README.386BSD, etc, are kind of gross.

Hmm, hmm, I agree.


>    c) The boot_i386 man page bears no resemblance whatsoever to
>       reality.

Reality is an illusion!


>    f) And, of course, is the stuff in netboot anywhere near to still
>       being useable?

Well, I've tried to use them, no-go.  I've tried to hack them, still no-go.
This could be *very* usefull, but I would need to get them working first.
Does *anyone* have the netboot stuff working?

Talking about booting, here is a thought for indigestion.  I've always
abhored (sp?) the crud that lies around in perfectly fine .../kern/* files,
which try to mount the root file system, etc.  Have you looked at the way
the root filesystem gets mounted over NFS nowadays?  YUK!!!  I personaly
(you don't have to share this view) think that this type of code, which
implements a hack to get bootparam, whatever network info, and then mounts
the FS from within the fs_init routine should be done elsewhere.  You ask
where?  Well, there is a little stub-process that tries to exec /sbin/init,
etc.  This process should be compiled like a "normal" program.  It could
then be loaded with the kernel somehow.  For example, tacking it on the end
of the kernel.  The kernel would then map those extra pages for this first
process.

natasha% cat ./netbsd ./starter > /netbsd

Note, this would give us a neat way of doing an embeded kernel, whatever.
All you would need to do, is have your program tacked on the end of /netbsd,
and have it started on boot.  It could use any kernel services (maybe
initializing them first ie: ethernet), as well as memory management, etc...

This would also help sorting things out among boot protocols.  Right now,
the NFS code seems to use bootparam, etc to find the root filesystem.  With
the code broken out, it would be almost trivial to setup the ethernet or
whatever device, and then get the info with any sort of protocol (bootp, etc)
that we wish to use.  By simply using different ./starter programs on the
end of /netbsd, we can boot and configure by different protocols.  It would also
configure swap, etc, etc...


>    g) Speaking of obsolete, how about arch/i386/Makefile...

I think the whole booting process is obsolete... ;-)

Anyways, wanted to get this off my chest.

--Toby.
*----------------------------------------------------------------------------*
| Tobias Weingartner | Email: weingart@BrandonU.Ca | Need a Unix sys-admin?  |
| Box 27, Beulah, MB |-----------------------------| Send E-Mail for resume, |
| R0M 0B0, Canada    | Unix Guru? Admin, Sys-Prgmr | and other details...    |
|----------------------------------------------------------------------------|
|      %SYSTEM-F-ANARCHISM, The operating system has been overthrown         |
*----------------------------------------------------------------------------*