[9fans] replacing 9load

[9fans] replacing 9load

[Russ Cox]

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

Re: [9fans] replacing 9load

[William Josephson]

On Mon, Dec 05, 2005 at 03:47:14PM -0500, Russ Cox wrote:
>     - write vm86 code for the kernel to replace the realmode
>       and will make the vesa and apm code run on more machines.

I might add that doing this shouldn't be too hard.
The FreeBSD vm86 is readable and I've ported it to
other systems recently.  I don't have time to do so
again, but the last time I did it, it was a day's worth
of work or so with the right manuals.  In any case, the
FreeBSD implementation is a good place to start if you
want to gauge how much work is involved.

Re: [9fans] replacing 9load

[Ronald G Minnich]

Russ Cox wrote:

>     - 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.

a thought here. We've been looking at the vga path for a few years, in 
the linuxbios project, and in fact precede the current plan 9 learning 
curve on vga by a bit.

In 2001 I wrote the equivalent of the Plan 9 realmode code for 
linuxbios, and put it in; it did pretty much the equivalent of what the 
realmode driver does now, and it worked, but it is really risky at 
times. Why? because the things that those VGA bios guys do are really 
evil. I can tell you stories ... too ugly to discuss in a family 
publication like 9fans. I'm very impressed that it is working so well.

I would ask people to consider looking at what we finally had to do in 
linuxbios, which is to put an x86 emulator. derived from the X11 x86 
emulator, into a driver. This works really well. You can catch evil 
things that the vga bios tries to do, and make them less evil. Also, 
such a driver would go in port/, not pc/. Just a thought.

But, long term, the approach of replacing 9load with plan9 sure makes a 
lot of sense. Is it possible some day that 9fat could go away, and we 
just load a kernel off of fossil? Just wondering.

ron

Re: [9fans] replacing 9load

[Charles Forsyth]

> emulator, into a driver. This works really well. You can catch evil 
> things that the vga bios tries to do, and make them less evil. Also, 
> such a driver would go in port/, not pc/. Just a thought.

why not put it in a program?

Re: [9fans] replacing 9load

[Russ Cox]

> I would ask people to consider looking at what we finally had to do in
> linuxbios, which is to put an x86 emulator. derived from the X11 x86
> emulator, into a driver. This works really well. You can catch evil
> things that the vga bios tries to do, and make them less evil. Also,
> such a driver would go in port/, not pc/. Just a thought.

This is way more code than doing vm86, though vm86 is gone on amd64,
so maybe it's necessary.  I tried doing this years ago with a home-grown
x86 simulator, and it didn't seem to run fast enough to appease the
hardware.

> But, long term, the approach of replacing 9load with plan9 sure makes a
> lot of sense. Is it possible some day that 9fat could go away, and we
> just load a kernel off of fossil? Just wondering.

Sure.  That could happen today if someone wrote the fossil
and venti parsing code for 9load.

Russ

Re: [9fans] replacing 9load

[Ronald G Minnich]

Charles Forsyth wrote:
>>emulator, into a driver. This works really well. You can catch evil 
>>things that the vga bios tries to do, and make them less evil. Also, 
>>such a driver would go in port/, not pc/. Just a thought.
> 
> 
> why not put it in a program?
> 

no reason not to, and we have one already. That's my preference anyway, 
I just said 'driver' as realmode driver is in the kernel.

ron

Re: [9fans] replacing 9load

[Ronald G Minnich]

Russ Cox wrote:

> This is way more code than doing vm86, 

quite true. I agree. But ... the code is written. We've tested the 
user-mode and linuxbios-mode code on a boatload (more than a truckload) 
of cards here and it works quite well. It has been tested most recently 
on a PCI-E card and it worked fine.

>though vm86 is gone on amd64,

yep. that's the problem. Well, one of the problems.

> so maybe it's necessary.  I tried doing this years ago with a home-grown
> x86 simulator, and it didn't seem to run fast enough to appease the
> hardware.

what we've seen here is that the x86 emulator is far faster than 
realmode. It's quite fun to watch the emulator bring cards up ... very 
fast. And, bringing multiple cards up is easy.

If we had a user-mode emulator, could we replace the realmode driver?

thanks

ron

Re: [9fans] replacing 9load

[Russ Cox]

> If we had a user-mode emulator, could we replace the realmode driver?

Sure, but it has to work for running the APM BIOS and also the
VESA BIOS calls that aux/vga uses.

Russ

Re: [9fans] replacing 9load

[Ronald G Minnich]

Russ Cox wrote:
>>If we had a user-mode emulator, could we replace the realmode driver?
> 
> 
> Sure, but it has to work for running the APM BIOS and also the
> VESA BIOS calls that aux/vga uses.

ok, I need to go do some more code reading. I was unaware of these bios 
calls!

Thanks

ron

Re: [9fans] Replacing 9load

[jmk]

On Mon Dec  5 14:42:57 EST 2005, leimy2k@gmail.com wrote:
> > 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.
> 
> Actually, it was meant for GNU Hurd as it loads microkernels and
> modules containing drivers and other bits of a "system" into separate
> address spaces.
> 
> GRUB2 works on PPC platforms as well now for the same effect.  [the
> solution for L4 based systems was to build a monolithic "piggybacked"
> image to achieve the multiboot effect]
> 

9load has been used on PPC platforms too.

> I agree chainloader is a bit of a pain in the ass.  Grub has
> filesystem modules and ways to do things like set VESA modes before
> you boot an OS [used with House for example... written in Haskell
> using the GHC runtime as OS services, yes ethernet drivers written in
> Haskell.]
> 

When I tried using the 'set vesa mode' fields in the multiboot header
it didn't work and I couldn't find anything in the source that did it.
Maybe I didn't look hard enough (GNU GRUB  version 0.96).

> grub is also capable of adding netboot capabilities to old PCs that
> didn't have the BIOS for it.  I used to boot an old P2 with a grub
> floppy to netboot OSes on it because it had no hard disk.
> 

GRUB failed miserbly here too. The machine I was using had an Intel 82557
and GRUB didn't recognise the PCI device number. I added it. GRUB still
wedges probing the network device more often than not.

> Grub has a lot of value to me as a result for some of these projects. 
> I've not seen another loader come along that can provide me with that
> level of configuration [besides perhaps OpenFirmware on my mac....
> even that needs Grub2 to do multiboot stuff though]
> 

I am sure GRUB is useful to some people, but not to me (see below).
Also, the Multiboot specification can't describe the conventional Plan 9
boot format, you either have to boot an ELF-format kernel or hack GRUB
to do special things if it recognises the Plan 9 binary (just like it has
to do for all the other O/S binaries).

> 
> 
> >
> > 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.
> 
> I just wish BIOS would die a quick painful death and we can move on to
> something else.  OpenFirmware would have been my preference but EFI
> appears to be the way for PCs.
> 
> >
> > 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
> >

Some of you will have seen this already, but here is a note I sent
to some interested parties early this year when I was initially
booting the AMD64:

if you are booting a 386 kernel then grub can do that already.
add the -H5 flag to your load line in the kernel mkfile and
make sure your l.s has the 'multiboot' label in it. you don't
currently get any plan9.ini or config stuff, but that's easy
to add (i have some of it in the amd64 test code).

i currently use grub to boot the amd64 test code over the network.
grub is on a floppy. i boot a small 386 bootstrap programme (kpc32)
which loads at 0x100020 using 'kernel'). i then load the amd64
kernel at 0x110000 using 'kernel', but it has an entry point of
0x100020, so the 'boot' command starts executing the 386 bootstrap
code which sets up page tables and long mode then jumps to 0x110000.

i used grub because i thought it would save me time, but grub is
just 9load's evil twin, it has all the same problems as 9load, e.g.
quirky syntax, flakey drivers ported in and hacked from other
systems, odd configuration files and so on. it regularly hangs
while probing the etherdevice.

here's booting plan9 code with grub:

Found Intel EtherExpressPro100 at 0xbc00, ROM address 0x0000
Probing...[Intel EtherExpressPro100]Ethernet addr: 00:E0:81:2A:3C:A6
Address: 135.104.9.32
Netmask: 255.255.255.0
Server: 135.104.9.7
Gateway: 135.104.9.1
Address: 135.104.9.32
Netmask: 255.255.255.0
Server: 135.104.9.2
Gateway: 135.104.9.1


    GNU GRUB  version 0.96  (639K lower / 4127680K upper memory)

 [ Minimal BASH-like line editing is supported.  For the first word, TAB
   lists possible command completions.  Anywhere else TAB lists the possible
   completions of a device/filename. ]

grub> root (nd)
 Filesystem type is tftp, using whole disk

grub> kernel /usr/jmk/k/pc32/kpc32
   [Multiboot-elf, <0x100020:0x378b:0x0>, <0x104000:0x21c:0x234>, shtab=0x10500
0, entry=0x100020]

grub> kernel /usr/jmk/k/pc64/kpc64 -a arg -fg foo bar
   [Multiboot-elf, <0x110000:0x3774:0x0>, <0x114000:0x570:0x1520>, shtab=0x1160
00, entry=0x100020]

grub> module /usr/jmk/tmp/plan9.ini
   [Multiboot-module @ 0x116000, 0x82 bytes]

grub> boot
Hello Squidboy 32
Hello Squidboy 64
1800MHz
&ax = ffffffff8010fff0, ax = 0x2badb002, bx = 0x36c40
magic 0x2badb002 pmbi 0x36c40
flags 0x7ef
cmdline </usr/jmk/k/pc64/kpc64 -a arg -fg foo bar>
mod 0x116000 0x116082 </usr/jmk/tmp/plan9.ini>
Memory
	0x0000000000000000 0x000000000009FC00 (654336)
reserved
	0x000000000009FC00 0x00000000000A0000 (1024)
reserved
	0x00000000000E0000 0x0000000000100000 (131072)
Memory
	0x0000000000116082 0x00000000FBFF0000 (4226654078)
ACPI Reclaim Memory
	0x00000000FBFF0000 0x00000000FBFFF000 (61440)
ACPI Non-Volatile-Sleeping Memory
	0x00000000FBFFF000 0x00000000FC000000 (4096)
reserved
	0x00000000FF7C0000 0x0000000100000000 (8650752)
space 0x00000000FC000000 0x00000000FF7C0000 (4277665792)
Memory
	0x0000000100000000 0x0000000180000000 (2147483648)
bootloadername <GNU GRUB 0.96>
pmem0: 0x0000000000116082 0x00000000fbed9f7e 0x00000000fbff0000
pmem1: 0x0000000100000000 0x0000000080000000 0x0000000180000000
cr3 = 0x108000
reset

--jim

Re: [9fans] Replacing 9load

[David Leimbach]

> 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.

Actually, it was meant for GNU Hurd as it loads microkernels and
modules containing drivers and other bits of a "system" into separate
address spaces.

GRUB2 works on PPC platforms as well now for the same effect.  [the
solution for L4 based systems was to build a monolithic "piggybacked"
image to achieve the multiboot effect]

I agree chainloader is a bit of a pain in the ass.  Grub has
filesystem modules and ways to do things like set VESA modes before
you boot an OS [used with House for example... written in Haskell
using the GHC runtime as OS services, yes ethernet drivers written in
Haskell.]

grub is also capable of adding netboot capabilities to old PCs that
didn't have the BIOS for it.  I used to boot an old P2 with a grub
floppy to netboot OSes on it because it had no hard disk.

Grub has a lot of value to me as a result for some of these projects. 
I've not seen another loader come along that can provide me with that
level of configuration [besides perhaps OpenFirmware on my mac....
even that needs Grub2 to do multiboot stuff though]



>
> 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.

I just wish BIOS would die a quick painful death and we can move on to
something else.  OpenFirmware would have been my preference but EFI
appears to be the way for PCs.

>
> 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
>

RE: [9fans] Replacing 9load

[C H Forsyth]

[-- Attachment #1: Type: text/plain, Size: 81 bytes --]

the BeBox was a more impressive example because
it was big-endian (dual powerpc)

[-- Attachment #2: Type: message/rfc822, Size: 2392 bytes --]

From: jmk@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: RE: [9fans] Replacing 9load
Date: Sun, 4 Dec 2005 14:29:43 -0500
Message-ID: <af3ffbda7d2c756d732bb624fb852279@plan9.bell-labs.com>

On Sun Dec  4 14:07:07 EST 2005, forsyth@terzarima.net wrote:
> >>Russ is also correct in his comments that the driver works on other
> >>architectures; at one time it worked on a BeBox.
> 
> so it did: i'd forgotten that!

ethel% grep sd53c8xx /sys/src/9/alphapc/apccpu
	sd53c8xx	pci sdscsi
ethel% 

RE: [9fans] Replacing 9load

[jmk]

On Sun Dec  4 14:07:07 EST 2005, forsyth@terzarima.net wrote:
> >>Russ is also correct in his comments that the driver works on other
> >>architectures; at one time it worked on a BeBox.
> 
> so it did: i'd forgotten that!

ethel% grep sd53c8xx /sys/src/9/alphapc/apccpu
	sd53c8xx	pci sdscsi
ethel% 

RE: [9fans] Replacing 9load

[Charles Forsyth]

>>Russ is also correct in his comments that the driver works on other
>>architectures; at one time it worked on a BeBox.

so it did: i'd forgotten that!

RE: [9fans] Replacing 9load

[Nigel Roles]

> kuroneko  the sym53cxxx comment came from the fact that if you
>          don't link in the sym53cxxx detection support into
>          9load and then boot a kenfs kernel, kenfs does not
>          see the 53cxxx [similarly, 9load also detonates violently if
>          you have a 53c810, 825 or 815 without SCRIPTS support]
>          somebody has updated the 53cxxx driver at some point,
>          and its definately not particularly friendly now
>          I'm pretty sure when I looked at the 2e 53cxxx driver,
>          it wasn't dependant on SCRIPTS

SCRIPTS is the name of the language used to program the SCSI sequencer
(specialised instruction set microprocessor if you like). It's possible that
it can also be used to name the sequencer itself. One thing for sure; all
53c8xx devices (including 10, 15, 25) all support it. It is a fundamental
feature of the entire chip range, and what distinguishes it from the earlier
53c7xx series.

Therefore I struggle to understand what not having SCRIPTS support means.

Now, it is just about possible to perform SCSI I/O without using the
sequencer, as the registers can be operated on directly; I guess this would
mean a driver which did not use SCRIPTS. Very early Lunix drivers for the
53c810 used it in this legacy mode, driven by modified 53c7xx drivers, but
even before the first Plan 9 driver was written, this approach was already
deprecated and NetBSD and Linux had SCRIPTS based drivers. The author of the
Plan 9 driver followed this approach.

Russ is also correct in his comments that the driver works on other
architectures; at one time it worked on a BeBox.

Re: [9fans] Replacing 9load

[Russ Cox]

Here is the context, which I think is relevant.  And if not,
it is at least illuminating of how these IRC discussions
snowball into beliefs that are far from the truth.


kuroneko  ACTION swears at 9load, old plan9 isos, and other
         issues
         rather than migrating my old kenfs, I have to take
         more drastic measures. *sigh*

uriel     oh, 9load, the horror, the horror :)

kuroneko  I swear, 9load is on my list...

uriel     "hit list"?

kuroneko  *nods*

uriel     hehe :)

kuroneko  9load must die.

uriel     kuroneko: take care of 9load, and I will owe you quite
         a few beers

kuroneko  its on my list after establish world peace.

uriel     hehehe...

kuroneko  it may get bumped up a few notches once I get sparc
         or mips working.

uriel     don't worry, I'm taking care of world peace
         ;)

lantis    ^^

kuroneko  but 9load must die.

uriel     ACTION says amen

kuroneko  I am really unhappy with the fact that 9load appears
         to pass information onto the sym53cxxx driver
         it means that the sym53cxxx driver will not work on
         non-x86
         and I'm sure I've outlined the other reasons why I
         feel so strongly about 9load's death...

...

kuroneko  9load needs to go away.

vt3       ok, but what replaces it?

kuroneko  x86 needs to either switch to booting via multiboot
         and a small multiboot loader gets written
         or all the hardware autodetect needs to be removed
         from 9load
         and 9load gets reduced to being able to bootstrap kernels
         from minimum state (and become PXE compatible).
         read: 9load does too much.

vt3       I like the reduction idea.

kuroneko  more of 9load's function belongs in the kernel propper.

vt3       so basically modularize the processes.

kuroneko  that way we can carry it over to other archs when appropriate

vt3       yeah, i understand.
         another solution is to have a 9load variant for other
         archs and leave 9load as is.
+vmhobbes

uriel     vt3: no, because 9load duplicates kernel functionality
         already, that would only make matters worse

vt3       well, there's x86 and then there's everything else.

uriel     vt3: and something so tricky and black-art as ide-proving
         you only want to do in one place

kuroneko  IDE probing isn't that black-art either IMO
         the fact that linux can do it with much better certainty
         and accuracy than 9load is fairly indicative of that
         IMO

vt3       if we move off 9load, what do we break?

uriel     kuroneko: I think it's due to higher user base, ide-proving
         is very bug-sensitive to bios and chipset issues

kuroneko  vt3: any driver thats stupid enough to depend on 9load.

uriel     vt3: we "break" the install CDs not working 50% of
         the time

__20h__   Moving plan9.ini into /boot.

kuroneko  basically, the biggest problem I have with current
         9 boot practice is that it follows the 'distrust the
         preboot environment' philosophy
         which ultimately works against you in the longer term.

uriel     kuroneko: I'm not so sure of that

kuroneko  a 9 cd bootloader should lever eltorito for example.

uriel     kuroneko: preboot-environments can't be relied on from
         what I have seen

kuroneko  uriel: unfortuantely you're stuck with them.

uriel     kuroneko: yea, but the PC is a hell of a swamp of 'standards
         and bugs'

kuroneko  and preboot environments are generally sane enough
         to boot your kernel and get the real stuff going

uriel     (how long until you can't boot new PCs without doing
         ACPI? already some boards hardly work without it)

vt3       so basically moving towards something as the obsd camp
         has today.
         but with a graphical install.

uriel     kuroneko: well, yea, I agree the kernel should deal
         with things, and that the boot loader should just "do
         enough to get the kernel"

kuroneko  ACPI belongs in the kernel if its to be there at all.
         I'm already going to be working on openfirmware devicetrees
         in the kernel

uriel     kuroneko: yes, I agree...

kuroneko  so sparc wont' require hardcoded magic numbers

uriel     kuroneko: but we should make sure that the kernel doesn't
         care who gets at it(ie., as you said, that 9load does
         as little as possible)

kuroneko  well, thats the thing.

uriel     cause I fear in the end some day we will be forced
         to boot from grub or some such abomination

kuroneko  if plan9x86 starts to conform to multiboot, we can
         start heading that way
         multiboot means grub works.
         it means a number of other first-stage booters work
         and it shouldn't be hard to write a minimal bootloader
         that can boot a plan9 multiboot compatible kernel

uriel     there are some not very kind words about grub and it's
         "Unified boot standards" things in 9fans archives

kuroneko  I guess I should search the archives sometime then.

__20h__   Plan 9 doesn't do multiboot?

vt3       well, does get the kernel mean get the drivers? i think
         our model relies on drivers being in the kernel, which
         in turn requires us to get rid of floppy installs which
         don't have enough room for a grand unified kernel.
         ;)

kuroneko  20h: 9load might be multiboot, but the kernel itself
         doesn't.

uriel     http://groups.google.com/group/comp.os.plan9/msg/2b2e7752e8208afe
         (that one is a classic)

kuroneko  the whole thing about pain is simply because plan9
         is basically a major misfit on most platforms.
         it ignores abi (which is a good thing sometimes, but
         not othertimes), it ignores host configuration services,
         it ignores standard disklabels and partition tables

uriel     doing things right seems to be a major misfit on most
         things in this world :(

kuroneko  uriel: I don't call ignoring the established protocol
         for you host system 'doing things right'
         instead, I consider it 'taking the easy way out'.

uriel     http://groups.google.com/group/comp.os.plan9/msg/7f681582d17af0a2

vt3       hmm, the 9load trinity (9load, 9fat, Plan9.ini). We
         should consider retiring 9fat as well perhaps.

__20h__   You have two possibilities: plan9.ini or a writeable
         /boot.

vt3       a writable /boot seems like an interesting idea.

uriel     ACTION isn't sure writeable /boot is worth the trouble

lantis    mbrfs :) ?

uriel     9fat isn't all that bad

vt3       it isn't that good either.

__20h__   Where are problems with 9fat?

uriel     vt3: it doesn't create as much trouble as 9load...

vt3       it really seems like a quick fix in the big picture
         of things.

__20h__   So you want fossil support for Grub?

vt3       i see them as being interelated.

uriel     vt3: it might look a bit ugly, but it's simple and
         it works

kuroneko  9fat is good. its simple.
         however, 9fat's partition should be a MBR partition
         not a plan9 partition

vt3       from a security standpoint i don't trust it.

uriel     yea, how 9fat is 'hosted' is a bit... weird..
         vt3: uh? you don't trust your hardrive? then tough
         luck

__20h__   'security standpoint' - which one?

vt3       local access and lack of permissions

__20h__   So you think fossil is more secure, when you boot some
         CD with -AWP?
         For local access will you need machine guns.

kuroneko  local access is a non issue.

uriel     vt3: in Plan 9 we have real security, not delusions
         of security

kuroneko  the terminal owner can screw things over just as easily
         with fossil.
         [non-issue as in: this is not an issue to be resolved]

uriel     exactly

vt3       ok, we'll revisit it later then. :)

__20h__   But EROS boots, so you can try it. :P

kuroneko  fossil is NOT suitable for bootloading either.

uriel     oh dear, vt3 would have loved the EROS presentation
         what a load of crap it was

__20h__   But they use some sort of 9P for their network communication.

uriel     __20h__: I thought they had given up on hvaing any
         kind of network at all

kuroneko  to boot from a fossil fs you'd need a full IP stack
         and venti client so you can pull files out of venti
         if they're ont in the fossil cache.

uriel     __20h__: I even asked him about it, and he said "too
         hard"

kuroneko  that is too complicated for a bootloader.

uriel     kuroneko: yea, not worth it either, doesn't earn you
         much over 9fat

__20h__   So pbs needs to be able to start the kernel image?

kuroneko  __20h__: basically.

__20h__   It will stay at the basics.

kuroneko  the other thing I like about 9fat is it drastically
         simplifies floppy booting.
         you're basically using the same fs parsing code for
         floppies as you do for small 9fat partitions

__20h__   " /* when boot is changed to only use rc, this code
         can go away */" (/sys/src/9/pc/main.c)
         How about that way?

uriel     more russ on grub:
http://groups.google.com/group/comp.os.plan9/msg/b2463c380db1f18d

kuroneko  the whole thing is, if 9fat was an MBR partition, grub
         could be configured out of it.
         invalidating the whole configuration thing.
         and it shouldn't be too hard to teach grub how to read
         its config out of plan9 9fat partitions either.
         its just a matter of teaching grub about plan9 partition
         tables

uriel     well, to be honest, I agree with russ that I can't
         understand why a boot loader should need so much 'configuration"

kuroneko  it doesn't.
         grub requires about the same amount as 9load.

uriel     dunno, maybe it's just that the docs are a mess, but
         every time I have tried to install grub by hand, it
         has been a nightmare

kuroneko  I've installed grub many times by hand.
         then again, I probably understand certain bits about
         x86 better than a lot of people.

uriel     well, like everyhting, once you know the right dance,
         I guess it's not hard
         better than me certainly :)

kuroneko  even the first time I installed grub wasn't too painful

uriel     but I can't see why grub should need me to understand
         that stuff(and really, it has it's own set of weirdines
         and peculiarities, like it's own way to name devices
         and so on)

kuroneko  the device naming thing is a pain.

lantis    yeah

kuroneko  but its one you're stuck with everywhere.
         every preboot environment labels devices its own way

lantis    it becomes really funny when you are dealing with BSDs..
         root (hd0,0,a) or some f'..

kuroneko  lantis: blame disklabel for that.

uriel     this is interesting:
http://groups.google.com/group/comp.os.plan9/msg/61aab4e96e69764b
         seems like russ changed his mind in the end
         (or he was being cynical?)

kuroneko  openboot paths shall not be mentioned.
         they are beyond evil
         and are only made managable by labels.
         ['boot disk:a' actually maps to 'boot /devices/../../.../sd@n:a'
         or some other magic on most openfirmware systems]
         SGI ARC labels disks in its own way...
         SRM labels disks in its own way
         etc
         preboot sucks because everybody does it different.
         tough biscuits.
         you just have to live with it.
         you (hopefully) spend under 1% of your time in your
         preboot environment.
         working out the correct disk 'name' isn't too hard
         fortunately in most preboot environments.
         and usually you set and forget.

vt3       seems like a good time to start a project or fork to
         prove a point, and without bothering folks at BL. just
         be creative without the hassles.

kuroneko  Its on my to-get-back-to list.

...

uriel     we got email

vt3       cool. i'm glad Russ is reading. life is good.

kuroneko  uriel: we did?

uriel     kuroneko: yes :)

kuroneko  greylisting slows my mail influx right down

uriel     kuroneko: check your mailbox :)
         ah, I see

kuroneko  so it'll be a while before it turns up
         uriel: summary?

vt3       that was a good email.

uriel     kuroneko: 9load must diea, but it's not as bad as it
         seems ;)
         (but maybe I misread , so dont' take my word)
         kuroneko: I can paste in query if you like

vt3       unix bias? I thought it was my DOS bias. ;)

kuroneko  uriel: hrm. try it. :) I hope irssi doesn't floodprot
         by default. :)

uriel     kuroneko: are you registered in this shit netowrk?
         if you are, I can't :/

kuroneko  yeah, I am.
         been around for too long ;)

uriel     then you will have to connect to irc.oftc.net; because
         I'm not registered, and they filter out msgs from non-registered
         users to registered users

kuroneko  ah
         bloody hell. :)

uriel     kuroneko: just join #plan9 in irc.oftc.net

kuroneko  the sym53cxxx comment came from the fact that if you
         don't link in the sym53cxxx detection support into
         9load and then boot a kenfs kernel, kenfs does not
         see the 53cxxx
         [similarly, 9load also detonates violently if you have
         a 53c810, 825 or 815 without SCRIPTS support]
         somebody has updated the 53cxxx driver at some point,
         and its definately not particularly friendly now
         I'm pretty sure when I looked at the 2e 53cxxx driver,
         it wasn't dependant on SCRIPTS

Re: [9fans] Replacing 9load

[jmk]

On Sat Dec  3 23:50:33 EST 2005, uriell@binarydream.org wrote:
> ...
> 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

gosh

[9fans] Replacing 9load

[Uriel]

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