[9fans] pc boot and ether drivers

[9fans] pc boot and ether drivers

[Tim Newsham]

Hi,  I noticed that the /sys/src/boot/pc ether drivers seem to
be at least somewhat based on the /sys/src/9/pc/ether* drivers,
but somewhat out of date.  What is the reason for seperately
maintained files (are the interfaces significantly different)?
How hard would it be to bring the boot ethernet drivers up to
date with the kernel files (or better to have them share code)?

Tim N.

Re: [9fans] pc boot and ether drivers

[geoff]

The internals of the bootstraps are different from the internals of
the kernels (which differ from each other).  For example, the kernels
have machinery such as kernel processes available to drivers.  Some of
these differences could be papered over with #defines and
compatibility functions.  On the other hand, the bootstrap drivers
don't have to be very sophisticated.

I'd love to have just one set of drivers, but there doesn't seem to be
much interest-and-energy available to reconcile the kernels with each
other and the bootstraps.

Re: [9fans] pc boot and ether drivers

[jmk]

It's mostly historic and most of the reasons have gone away.
Sharing code with the current 9load code would be more trouble
than it's worth. There are ideas for doing a better job by
rewriting the bootstrap altogether, but who knows if/when it
will ever be done.

On Tue Nov 16 20:56:10 EST 2004, newsham@lava.net wrote:
> Hi,  I noticed that the /sys/src/boot/pc ether drivers seem to
> be at least somewhat based on the /sys/src/9/pc/ether* drivers,
> but somewhat out of date.  What is the reason for seperately
> maintained files (are the interfaces significantly different)?
> How hard would it be to bring the boot ethernet drivers up to
> date with the kernel files (or better to have them share code)?
> 
> Tim N.

Re: [9fans] pc boot and ether drivers

[Vester Thacker]

On Tue, 16 Nov 2004 21:11:42 -0500, jmk@plan9.bell-labs.com
<jmk@plan9.bell-labs.com> wrote:
> It's mostly historic and most of the reasons have gone away.
> Sharing code with the current 9load code would be more trouble
> than it's worth. There are ideas for doing a better job by
> rewriting the bootstrap altogether, but who knows if/when it
> will ever be done.

Are you looking for volunteers for creating a new
bootstrap? If so, then maybe a working group 
could be formed... something akin to what EricVH 
has done with v9fs. 

-vester

Re: [9fans] pc boot and ether drivers

[Eric Van Hensbergen]

On Thu, 18 Nov 2004 09:54:40 +0900, Vester Thacker
<vester.thacker@gmail.com> wrote:
> On Tue, 16 Nov 2004 21:11:42 -0500, jmk@plan9.bell-labs.com
> <jmk@plan9.bell-labs.com> wrote:
> 
> Are you looking for volunteers for creating a new
> bootstrap? If so, then maybe a working group
> could be formed... something akin to what EricVH
> has done with v9fs.
> 

Personally, I'd rather see us punt on the whole loader issue
where-ever possible.  It seems reasonable enough to use "other
people's loaders" to boot Plan 9.  I believe Ron talks about booting
Plan 9 from LinuxBIOS on the Wiki and I'm sure other loaders could be
made to work.  We have enough to do without having to worry about
writing boot loaders.

          -eric

Re: [9fans] pc boot and ether drivers

[Karl Magdsick]

How difficult would it be to make the Plan9 kernel compliant with the
MultiBoot standard?

This would seem to be the path of least resistance for getting the
Plan9 kernel working with other bootloaders.  In addition to working
"out of the box" with MultiBoot bootloaders, there are tools that will
wrap any MultiBoot kernel (plus any modules) along with some stub code
into an image that can be booted by any bootloader that can boot a
Linux kernel.  There is a similar tool to get any MultiBoot kernel
(plus any modules) to mimic one of the BSD kernels.


-Karl

On Wed, 17 Nov 2004 19:28:20 -0600, Eric Van Hensbergen
<ericvh@gmail.com> wrote:
> On Thu, 18 Nov 2004 09:54:40 +0900, Vester Thacker
> <vester.thacker@gmail.com> wrote:
> > On Tue, 16 Nov 2004 21:11:42 -0500, jmk@plan9.bell-labs.com
> > <jmk@plan9.bell-labs.com> wrote:
> >
> > Are you looking for volunteers for creating a new
> > bootstrap? If so, then maybe a working group
> > could be formed... something akin to what EricVH
> > has done with v9fs.
> >
> 
> Personally, I'd rather see us punt on the whole loader issue
> where-ever possible.  It seems reasonable enough to use "other
> people's loaders" to boot Plan 9.  I believe Ron talks about booting
> Plan 9 from LinuxBIOS on the Wiki and I'm sure other loaders could be
> made to work.  We have enough to do without having to worry about
> writing boot loaders.
> 
>           -eric
>

Re: [9fans] pc boot and ether drivers

[geoff]

The main complication is that the Plan 9 bootstraps also read and
parse plan9.ini and leave the results in a known place for the loaded
kernel.  I suppose that code could be moved into the kernels.

Re: [9fans] pc boot and ether drivers

[Tim Newsham]

> The main complication is that the Plan 9 bootstraps also read and
> parse plan9.ini and leave the results in a known place for the loaded
> kernel.  I suppose that code could be moved into the kernels.

Changing them to cmd line arguments should be fairly straightforward,
no?  Dont most the other platforms (other than "386") get by
without a .ini file?

Tim N.

Re: [9fans] pc boot and ether drivers

[geoff]

Command line to what?  The kernels don't have command lines.

The other platforms generally are much better defined.  The PC just
happened, and so there's all sorts of ad hocery to cope with, such as
the lack of a proper boot prom capable of bootp/dhcp/tftp loading and
of accepting console configuration commands.  The alphapc port
actually does read a plan9.ini file from /alpha/conf, much like the
newer /cfg/pxe.  Of course you have to be able to find your main
Ethernet interface in order to load those files...

Re: [9fans] pc boot and ether drivers

[Russ Cox]

the other platforms run on much less variable
hardware so the config can easily be hard-wired.

russ

Re: [9fans] pc boot and ether drivers

[Tim Newsham]

> Command line to what?  The kernels don't have command lines.

Many boot loaders provide arguments to the booting kernel.
I don't think it should be very difficult to craft a command
line such as:

   9pcdisk bootdisk=local!#S/sdC0/fs *nomp=1 monitor=multisync75
		vgasize=1024x768x8

parsing this out from a single argument buffer should be a
trivial addition to the current sources.  Looks like getting
at this data is pretty simple:

http://www.gnu.org/software/grub/manual/multiboot/html_node/Boot-information-format.html#Boot%20information%20format

Tim N.

Re: [9fans] pc boot and ether drivers

[Russ Cox]

the boot process is crappy enough.
let's not make it crappier.

Re: [9fans] pc boot and ether drivers

[bs]

geoff@collyer.net wrote:
> Command line to what?  The kernels don't have command lines.
> 
> The other platforms generally are much better defined.  The PC just
> happened, and so there's all sorts of ad hocery to cope with, such as
> the lack of a proper boot prom capable of bootp/dhcp/tftp loading and
> of accepting console configuration commands.  The alphapc port
> actually does read a plan9.ini file from /alpha/conf, much like the
> newer /cfg/pxe.  Of course you have to be able to find your main
> Ethernet interface in order to load those files...
in the case of PXE boot why not get it from a DHCPREQUEST?

Re: [9fans] pc boot and ether drivers

[Vester Thacker]

On Wed, 17 Nov 2004 18:43:22 -0800, geoff@collyer.net <geoff@collyer.net> wrote:
> The main complication is that the Plan 9 bootstraps also read and
> parse plan9.ini and leave the results in a known place for the loaded
> kernel.  I suppose that code could be moved into the kernels.

Couldn't we have a single large kernel with all the 
drivers for installation purposes? Could we have 
the user build and/or a kernel during the install 
process for the type of Plan 9 computer that is 
desired rather than the current scheme? Would 
this lessen the need for a plan9.ini during the 
initial installation bootstrap?

I don't advocate plan9.ini being depreciated, only
that it should not be required initially. IMHO this 
might be advantagous considering floppy drives 
are obsolete. Sorry if this obfuscates the matter
a bit.

-vester

Re: [9fans] pc boot and ether drivers

[Vester Thacker]

On Thu, 18 Nov 2004 13:26:38 +0900, Vester Thacker
<vester.thacker@gmail.com> wrote:

>Could we have the user build and/or a kernel 
>during the install process for the type of Plan 9 
>computer that is desired rather than the current 
>scheme?

Sorry, that should have read:
Could we have the user build and/or select a 
kernel during the install process for the type of 
Plan 9 computer that is desired rather than the 
current scheme? 

-vester

Re: [9fans] pc boot and ether drivers

[jmk]

On Tue, 16 Nov 2004 21:11:42 -0500, jmk@plan9.bell-labs.com
<jmk@plan9.bell-labs.com> wrote:
> It's mostly historic and most of the reasons have gone away.
> Sharing code with the current 9load code would be more trouble
> than it's worth. There are ideas for doing a better job by
> rewriting the bootstrap altogether, but who knows if/when it
> will ever be done.

By 'rewriting the bootstrap altogether' I would make it go away
altogether and use the kernel to boot another kernel. We can do this
already but some of the details are a bit messy and a tidy up and
re-organisation would be a good idea; this is likely to fall out
of something else I hope to be doing soon. How you get the first
(bootstrap) kernel into memory could be the same as now, using
whatever methods you like - Plan 9 MBR/PBS, Grub, LILO, LinuxBIOS,
PXE, whatever.

On Wed Nov 17 20:29:00 EST 2004, ericvh@gmail.com wrote:
> ...
> We have enough to do without having to worry about
> writing boot loaders.
> 
>           -eric

Agreed.

On Wed Nov 17 23:01:38 EST 2004, russcox@gmail.com wrote:
> the boot process is crappy enough.
> let's not make it crappier.

Agreed.

--jim

Re: [9fans] pc boot and ether drivers

[Vester Thacker]

On Wed, 17 Nov 2004 23:53:23 -0500, jmk@plan9.bell-labs.com
<jmk@plan9.bell-labs.com> wrote:
> 
> By 'rewriting the bootstrap altogether' I would make it go away
> altogether and use the kernel to boot another kernel. We can do this
> already but some of the details are a bit messy and a tidy up and
> re-organisation would be a good idea; this is likely to fall out
> of something else I hope to be doing soon. How you get the first
> (bootstrap) kernel into memory could be the same as now, using
> whatever methods you like - Plan 9 MBR/PBS, Grub, LILO, LinuxBIOS,
> PXE, whatever.
> 
> On Wed Nov 17 20:29:00 EST 2004, ericvh@gmail.com wrote:
> > ...
> > We have enough to do without having to worry about
> > writing boot loaders.
> >
> >           -eric
> 
> Agreed.
> 
> 
> 
> On Wed Nov 17 23:01:38 EST 2004, russcox@gmail.com wrote:
> > the boot process is crappy enough.
> > let's not make it crappier.
> 
> Agreed.
> 
> --jim
> 

Sorry to be the one to say this, but to me that comes off like "don't
futz with code until we get our projects done". Where is the openness
in that?  Maybe it's just me. I'll drop the subject.

-vester

Re: [9fans] pc boot and ether drivers

[geoff]

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

That's just plan9.ini with data supplied by a different boot loader,
presumably at a different memory address.

I'd rather have the kernel pick the first (supported) ethernet
interface in the PCI tables and use that to boot load via /cfg/pxe,
thus putting the plan9.ini's in one place.

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

From: Tim Newsham <newsham@lava.net>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] pc boot and ether drivers
Date: Wed, 17 Nov 2004 17:54:51 -1000 (HST)
Message-ID: <Pine.BSI.4.58.0411171749100.6130@malasada.lava.net>

> Command line to what?  The kernels don't have command lines.

Many boot loaders provide arguments to the booting kernel.
I don't think it should be very difficult to craft a command
line such as:

   9pcdisk bootdisk=local!#S/sdC0/fs *nomp=1 monitor=multisync75
		vgasize=1024x768x8

parsing this out from a single argument buffer should be a
trivial addition to the current sources.  Looks like getting
at this data is pretty simple:

http://www.gnu.org/software/grub/manual/multiboot/html_node/Boot-information-format.html#Boot%20information%20format

Tim N.

Re: [9fans] pc boot and ether drivers

[C H Forsyth]

>>Sorry to be the one to say this, but to me that comes off like "don't
>>futz with code until we get our projects done". Where is the openness
>>in that?  Maybe it's just me. I'll drop the subject.

not really.  i think it's more along the lines of:
if someone is looking for something to do that would be particularly
helpful, at the moment, of all the things that we might suggest, the
bootstrap would not be placed high on the list, even though no one
regards having to fuss with plan9.ini as a good thing.

Re: [9fans] pc boot and ether drivers

[Vester Thacker]

On Thu, 18 Nov 2004 10:39:40 0000, C H Forsyth <forsyth@vitanuova.com> wrote:
> 
> not really.  i think it's more along the lines of:
> if someone is looking for something to do that would be particularly
> helpful, at the moment, of all the things that we might suggest, the
> bootstrap would not be placed high on the list, even though no one
> regards having to fuss with plan9.ini as a good thing.

Thanks, Charles. Point taken. I apologize for my 
earlier statement and would like to retract it. 
Sometimes I take things more seriously than I
should. 

-vester

Re: [9fans] pc boot and ether drivers

[Ronald G. Minnich]

On Thu, 18 Nov 2004, Vester Thacker wrote:

> Are you looking for volunteers for creating a new
> bootstrap? 

why bother, I wonder. We've found plan 9 itself is a very nice bootstrap, 
and I've used it that way in clusters. 

convert plan 9 to an elf image, point grub or whatever at it, voila, done. 

I think you're better off making it easy to use Plan 9 as a bootstrap than 
to write a new 9load ...

ron

Re: [9fans] pc boot and ether drivers

[Ronald G. Minnich]

On Thu, 18 Nov 2004, Vester Thacker wrote:

> I don't advocate plan9.ini being depreciated, only
> that it should not be required initially. 

I'd like to deprecate it ... if only to get rid of the need for 9fat. 

Also, the various loaders can handle the file systems that the OSes use.  
Grub parses ext2, for example, which seems gross (ok, it's gross) but is
also VERY handy.

9load can't handle plan 9 file systems at all. It would be nicer (for me
anyway) if the plan 9 loader could parse plan 9 file systems, and I don't
see an easy way to do that with anything but a plan 9 kernel and the file
systems it supports set up as the loader image. Again, I do this now here 
at LANL, and it is pretty nice.

ron