From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sun, 4 Dec 2005 04:48:33 +0000 From: Uriel To: 9fans <9fans@cse.psu.edu> Message-ID: <20051204044833.GD9700@server4.lensbuddy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 Subject: [9fans] Replacing 9load Topicbox-Message-UUID: b78592b6-ead0-11e9-9d60-3106f5b1d025 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 ----- From: Russ Cox 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