9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] Replacing 9load
@ 2005-12-04  4:48 Uriel
  2005-12-04  7:01 ` jmk
                   ` (2 more replies)
  0 siblings, 3 replies; 18+ messages in thread
From: Uriel @ 2005-12-04  4:48 UTC (permalink / raw)
  To: 9fans

This email came as answer to some discussion in irc about how to replace
9load, I found it too informative to be left to rot in my mailbox, and
russ agreed to let me post it to 9fans if I provided some context, my
memory of the details of the discussion is dim, but after re-reading the
email it seems all in it stands well on it's own.


----- Forwarded message from Russ Cox <rsc@swtch.com> -----

From: Russ Cox <rsc@swtch.com>
Date: Sun, 9 Oct 2005 11:05:44 -0400
To: Uriel, Chris Collins, Vester Thacker
Subject: 9load

What makes you think sd53c8xx requires 9load?
It ran on the alphapc just fine without 9load.
9load is a clumsy hack, but the only alternatives
seem to be to depend on external programs like
grub.  Pxeboot may come along and save the day,
but until recently there was no established way to
load a kernel over the ethernet with some extra
options, so we had to roll our own.

As for putting plan9.ini in /boot, that just betrays
your Unix bias.  On Plan 9 terminals there is no
local file system, hence no /boot.  We boot most of
our terminals at Bell Labs off floppies, to avoid
touching the local disks at all.  All this said, 9load
is happy to read plan9.ini out of a kfs file system,
and someone with appropriate determination could
make it work with fossil or even venti+fossil.

The Plan 9 kernels (not 9load) already have multiboot
headers in them for use with grub.  Look at l.s.

I think Chris's understanding of 9load being essential
to the initialization of the kernel is misplaced.  The only
thing that 9load leaves around for the kernel is the apm
info, and even that is gone in my new vga kernels.
9load exists only to put plan9.ini and the kernel in memory.
It does not do device initialization.

The /dev/reboot stuff in the kernel is actually a step toward
replacing 9load with a real Plan 9 kernel that would fetch
kernel, config, etc. over the network (perhaps even using 9P
to talk to a real file server instead of all these hacky mini-protocols)
and then set the config and "reboot" to start the new kernel.
Continuing down that road may be worthwhile.

My comments about grub still stand.  It's great for booting
Linux kernels, which it was designed for, and it is okay for
chainloading to get to Plan 9.  I still think Smart Boot Manager
is far and away the best PC multi-OS booter out there.  It looks
at the partitions and says "here is what I found: pick one."
No manual config.  In grub you have to boot to Linux to tell it
about a new Plan 9 partition.  Grub is really a Linux loader
disguised as a multiboot loader.  In that situation it works great.
Beyond that it's just a pain.

Finally, do not believe even for a moment that Plan 9 thinks
that all the world's a 386.  We have always had a couple other
architectures running, and running well.  That's still true today.
On the other hand, if you're writing a pc kernel, you're going
to have to do some pc-specific things.

Russ

----- End forwarded message -----

If I can find the irc logs I'll post them for context, but I don't think
any of us said anything very useful.

uriel


^ permalink raw reply	[flat|nested] 18+ messages in thread
* [9fans] replacing 9load
@ 2005-12-05 20:47 Russ Cox
  2005-12-05 20:52 ` William Josephson
  2005-12-05 21:02 ` Ronald G Minnich
  0 siblings, 2 replies; 18+ messages in thread
From: Russ Cox @ 2005-12-05 20:47 UTC (permalink / raw)
  To: 9fans

For quite a few years, various of us have talked about
replacing 9load.  When Jim and I replaced b.com with the
combination of ld.com and 9load, we considered using a stock
Plan 9 kernel instead.  Sean Quinlan took a few steps toward
making this possible: he added the configuration environment
#ec, the Dev.shutdown routines, and /dev/reboot.  With
these, one can use the kernel as an impromptu boot loader
already.  I believe Ron Minnich does just that in some of
his machines.

There are a few things 9load does that the kernel depends
on.  The main one is loading plan9.ini from somewhere and
leaving it in memory.  A secondary one is setting up the APM
BIOS interface, and in the original VESA code written for
Inferno, 9load was responsible for setting up the VGA.  With
the new realmode code (or better, if someone would write it,
VM86 code) in the kernel, the APM and VESA can be done by
the kernel proper.  That leaves plan9.ini.

Plan9.ini serves two related but different purposes.  The
first is to give the kernel hints about hardware
recognition.  The second is to specify a few aspects of the
software configuration.  Ideally, it would be nice if
plan9.ini could become optional.

Hardware recognition was a much bigger problem in the old
ISA days.  Plan9.ini was, at the time, an excellent
alternative to recompiling the kernel to hard-wire all the
constants about your machine.  Now that we have PCI and its
device ids, you don't need to tell the kernel what hardware
you have anymore.  It knows, usually better than you.

That leaves the software configuration: mouse, vga, serial
console, kernel location, root file system location, boot
menu, etc.  The mouse and vga could possibly be
auto-detected, and the new vga resize code (if it works)
makes it possible to correct a bad guess about the user's
desired screen size.

The other options in plan9.ini -- the serial console, the
kernel and root file system, the boot menu -- can't just be
guessed.  Jim has been playing with loading plan9.ini via
PXE/TFTP, which is great for a real single-file-server Plan 9
setup, though it won't satisfy the single-machine users.
I don't expect this part of plan9.ini to go away, though one
could make 9load do without it in the general case (scan the
local 9fats for files named 9pc*, for example).

When I put the new mmu code into the kernels, I didn't feel
like putting it into 9load too.  Instead I wrote a small
binary that turns a gzipped kernel into a 9load binary that
the PBS bootstrap could load into memory.  You run

	cat load 9pcload.gz >9load
	
to produce a 9load from a kernel.  I have put this in
/n/sources/contrib/rsc/load.

This new program means that you can build yourself a special
pcload kernel with some 9load-like user-level program
installed as /boot/boot instead of the usual boot.  It would
find plan9.ini, present any prompts if needed, find and load
a kernel, and then /dev/reboot into it.  You could put
dossrv, ext2srv, fossil, venti, kfs, factotum, mount, tftp,
ftpfs, hget, etc., into the root file system, to load
kernels off of any conceivable medium.

While a new 9load using the real kernel could be great, it's
not very high on my or Jim's to do list, since the current
9load suffices, and we're more interested in what happens
once the kernel is in memory than the mundane and now
all-too-familiar details of the x86 boot process.

I encourage those of you grumbling for a new 9load to attack
one of the following problems:

    - write vm86 code for the kernel to replace the realmode
      code.  vm86 code should be safer and more reliable
      and will make the vesa and apm code run on more machines.

    - write a mouse auto-detector: scan the usb, try ps2,
      scan the serial ports.  this should be almost trivial.

    - write a vga size auto-detector: try aux/vga -m vesa -p
      and fetch and parse the edid information from the
      monitor.  aux/vga does most of this already.

    - write a user-level program to be the `9load' in a
      9pcload kernel.  the program should have generic "get me
      a plan9.ini" and "get me a kernel" interfaces, like the
      current 9load, so that many boot methods can be plugged
      in.

Ironically, once this is all done we'll have moved full circle to
where Plan 9 was many years ago, when the hobbit boot loader
was just a Plan 9 kernel with a different load address and a
special boot program that let you set environment variables,
examine memory, attach to file servers, run programs that
were downloaded, and load and boot a kernel.

Russ


^ permalink raw reply	[flat|nested] 18+ messages in thread
end of thread, other threads:[~2005-12-06  0:19 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-12-04  4:48 [9fans] Replacing 9load Uriel
2005-12-04  7:01 ` jmk
2005-12-04 16:00 ` Russ Cox
2005-12-04 16:56   ` Nigel Roles
2005-12-04 19:07     ` Charles Forsyth
2005-12-04 19:29       ` jmk
2005-12-04 22:13         ` C H Forsyth
2005-12-05 19:42 ` David Leimbach
2005-12-05 20:11   ` jmk
2005-12-05 20:47 [9fans] replacing 9load Russ Cox
2005-12-05 20:52 ` William Josephson
2005-12-05 21:02 ` Ronald G Minnich
2005-12-05 21:06   ` Charles Forsyth
2005-12-05 23:22     ` Ronald G Minnich
2005-12-05 21:21   ` Russ Cox
2005-12-05 23:27     ` Ronald G Minnich
2005-12-05 23:33       ` Russ Cox
2005-12-06  0:19         ` Ronald G Minnich

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).