FILO 0.4

[SONE Takeshi]

I just released FILO 0.4.
http://te.to/~ts1/filo/

It can boot distro CDs if you give a proper command line.
SuSE 8.2 LiveEval CD worked without a glitch, I enjoyed the
KDE desktop, OpenOffice, etc, from the CD on an EPIA booted
from LinuxBIOS.

Also added support for booting from BIOS flash, to boot an
alternative bootloader like Etherboot.

PCI support in IDE driver is also added (or recovered), but
the native PCI mode is not fully tested.
I tried to configure EPIA (V1) code to use native mode,
and the ports read something not 0xff, but the drive doesn't
respond to soft reset.
I don't know the bug is in FILO, LinuxBIOS, or the hardware.

I'll work on config file support next time.

Version 0.4 ts1 2003-10-15
    * Support for ATAPI CD-ROM.
    * ISO-9660 filesystem is taken from a GRUB patch by
      Leonid Lisovskiy . The filesystem code was originally
      written by Kousuke Takai  for GRUB/98 project.
    * Support for mounting boot disk image of El Torito bootable CD-ROM.
      ("hdc1" means the boot disk image of the CD-ROM at hdc.)
    * Support for memory as device, raw device as image, and
      user-specifiable device offset and length.
      (eg. boot: mem@0xfffd0000,0x10000)
    * PCI support in IDE driver. Now it by default uses PCI enumeration
      to find the PCI IDE controller, and can use native PCI mode
      if the controller is configured to this mode by BIOS.
      To disable this, turn off SUPPORT_PCI.
    * Fixed Linux loader to boot RedHat 9 kernel properly.

[Andrew Ip]

Hi SONE,
> It can boot distro CDs if you give a proper command line.
> SuSE 8.2 LiveEval CD worked without a glitch, I enjoyed the
> KDE desktop, OpenOffice, etc, from the CD on an EPIA booted
> from LinuxBIOS.

Wonder full.  Does X work?
> PCI support in IDE driver is also added (or recovered), but
> the native PCI mode is not fully tested.
> I tried to configure EPIA (V1) code to use native mode,
> and the ports read something not 0xff, but the drive doesn't
> respond to soft reset.
> I don't know the bug is in FILO, LinuxBIOS, or the hardware.

IIRC, EPIA has to use compatible mode; otherwise, system will
have problem with IRQ.

-Andrew

[SONE Takeshi]

On Wed, Oct 15, 2003 at 09:50:56PM +0800, Andrew Ip wrote:
> > It can boot distro CDs if you give a proper command line.
> > SuSE 8.2 LiveEval CD worked without a glitch, I enjoyed the
> > KDE desktop, OpenOffice, etc, from the CD on an EPIA booted
> > from LinuxBIOS.
>
> Wonder full.  Does X work?

Yes, X works if VGABIOS is used.
> > I tried to configure EPIA (V1) code to use native mode,
> > and the ports read something not 0xff, but the drive doesn't
> > respond to soft reset.
> > I don't know the bug is in FILO, LinuxBIOS, or the hardware.
>
> IIRC, EPIA has to use compatible mode; otherwise, system will
> have problem with IRQ.

I don't use IRQ. According to the comment in the southbridge code,
it has speed problem when native mode. I took that it does work
in native mode..

[Ronald G. Minnich]

On Wed, 15 Oct 2003, Andrew Ip wrote:
> > PCI support in IDE driver is also added (or recovered), but
> > the native PCI mode is not fully tested.
> > I tried to configure EPIA (V1) code to use native mode,
> > and the ports read something not 0xff, but the drive doesn't
> > respond to soft reset.

I always had trouble with the 8231 native mode 3 years ago. I ended up 
giving up and always using compatibility mode.

I will try to fix compat. mode in v2.

ron

SONE Takeshi  writes:
> I just released FILO 0.4.
> http://te.to/~ts1/filo/
>
> I'll work on config file support next time.

Is this work still ongoing?  At first stab at a config
file could hard code it's location like you currently do
the kernel image.

Another question listing files.  Currently you have that 
support completely removed from the Grub code.  Any thoughts
on adding that.

Eric

答复: FILO 0.4

[Yinghai Lu]

It seems someone (Greg ???) merge FILO into the LinuxBIOS hardwaremain.c and
it is can be loaded instead of elfboot.

In normal bios, when booting Etherboot with ASK_BOOT, and using Q can exit
from Etherboot and back into BIOS, then can boot into HD and use HD
bootloader.

In LinuxBIOS, if LinuxBIOS is using elfboot to boot Etherboot elf, when Q
from Etherboot, should continue to do the code after elfboot. So may put the
filo after elfboot.

But I think the best way is merged filo into Etherboot instead of Linuxbios
directly. Then We can use tg3-fs_stream.zelf or tg3_filo.zelf as payload of
LinuxBIOS.

It is more better if filo support boot loader (lilo) in HD.

Regards

Yinghai Lu

-----邮件原件-----
发件人: [e-mail]
[mailto:[e-mail]] 代表 Eric W. Biederman
发送时间: 2004年4月3日 13:02
收件人: SONE Takeshi
抄送: [e-mail]
主题: Re: FILO 0.4

SONE Takeshi  writes:
> I just released FILO 0.4.
> http://te.to/~ts1/filo/
>
> I'll work on config file support next time.

Is this work still ongoing?  At first stab at a config
file could hard code it's location like you currently do
the kernel image.

Another question listing files.  Currently you have that 
support completely removed from the Grub code.  Any thoughts
on adding that.

Eric
_______________________________________________
Linuxbios mailing list
[e-mail]
http://www.clustermatic.org/mailman/listinfo/linuxbios

答复: FILO 0.4 [PMX:#]

[Greg Watson]

Yeah sorry, I kind of did that by stealth. Ron and I get lots of 
requests from people wanting to use LB but who don't know how to deal 
with the payload issue. We decided that it would be really nice to have 
a simple bootloader that understands some basic filesystems built into 
LB. That way people can get going without having to deal with etherboot 
or FILO directly. A nice side effect is that it simplifies the FILO 
code significantly - in fact the only code that is really required is 
the filesystem support. Also, another major plus is that the code 
supports PPC as well as x86. Up to now I've had no bootloaders 
(etherboot or FILO) that work on PPC.

Greg

On 03/04/2004, at 4:56 PM, Yinghai Lu wrote:
> It seems someone (Greg ???) merge FILO into the LinuxBIOS 
> hardwaremain.c and
> it is can be loaded instead of elfboot.
>
> In normal bios, when booting Etherboot with ASK_BOOT, and using Q can 
> exit
> from Etherboot and back into BIOS, then can boot into HD and use HD
> bootloader.
>
> In LinuxBIOS, if LinuxBIOS is using elfboot to boot Etherboot elf, 
> when Q
> from Etherboot, should continue to do the code after elfboot. So may 
> put the
> filo after elfboot.
>
> But I think the best way is merged filo into Etherboot instead of 
> Linuxbios
> directly. Then We can use tg3-fs_stream.zelf or tg3_filo.zelf as 
> payload of
> LinuxBIOS.
>
> It is more better if filo support boot loader (lilo) in HD.
>
> Regards
>
> Yinghai Lu
>
> -----邮件原件-----
> 发件人: [e-mail]
> [mailto:[e-mail]] 代表 Eric W. Biederman
> 发送时间: 2004年4月3日 13:02
> 收件人: SONE Takeshi
> 抄送: [e-mail]
> 主题: Re: FILO 0.4
>
> SONE Takeshi  writes:
> > I just released FILO 0.4.
> > http://te.to/~ts1/filo/
> >
> > I'll work on config file support next time.
>
> Is this work still ongoing?  At first stab at a config
> file could hard code it's location like you currently do
> the kernel image.
>
> Another question listing files.  Currently you have that
> support completely removed from the Grub code.  Any thoughts
> on adding that.
>
> Eric
> _______________________________________________
> Linuxbios mailing list
> [e-mail]
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>
> Linuxbios mailing list
> [e-mail]
> http://www.clustermatic.org/mailman/listinfo/linuxbios

[ron minnich]

I was wondering about listing files. Once you add that, you add a command 
interpreter, and that way lies madness.

If, however, file listed all the files it found while attempting to load 
an image, that might be enough.

ron

FILO 0.4 [PMX:#]

[Yinghai Lu]

The current ide_disk part in Etherboot only scan 10 (???) sectors from
/dev/hda header. So the user muse cat boot.elf /dev/hda, I have modified
Etherboot source code to scan more sectors so it can find elf in /dev/hda1.
(the /dev/hda1 should be physical partition 1). The Linux Distribution is
installed from /dev/hda2. then I can use kernel and initrd in /boot to
produce elf and cat that in /dev/hda1. After that, I can boot from NIC or HD
via cmos conf.

The Etherboot group seems to stop enhancing the ide_disk part. I think maybe
because
> In normal bios, when booting Etherboot with ASK_BOOT, and using Q can exit
> from Etherboot and back into BIOS, then can boot into HD and use HD

bootloader.

And most users of Etherboot are from Normal BIOS ???? ( they don't like pxe
??)

How much works need to done to put filo in Etherboot for LinuxBIOS users?

PS: Nobody in PPC is using Etherboot???

Regards

YH

-----邮件原件-----
发件人: Greg Watson [mailto:[e-mail]] 
发送时间: 2004年4月3日 17:29
收件人: Yinghai Lu
抄送: 'SONE Takeshi'; 'Eric W. Biederman'; [e-mail]
主题: Re: 答复: FILO 0.4 [PMX:#]

Yeah sorry, I kind of did that by stealth. Ron and I get lots of 
requests from people wanting to use LB but who don't know how to deal 
with the payload issue. We decided that it would be really nice to have 
a simple bootloader that understands some basic filesystems built into 
LB. That way people can get going without having to deal with etherboot 
or FILO directly. A nice side effect is that it simplifies the FILO 
code significantly - in fact the only code that is really required is 
the filesystem support. Also, another major plus is that the code 
supports PPC as well as x86. Up to now I've had no bootloaders 
(etherboot or FILO) that work on PPC.

Greg

On 03/04/2004, at 4:56 PM, Yinghai Lu wrote:
> It seems someone (Greg ???) merge FILO into the LinuxBIOS 
> hardwaremain.c and
> it is can be loaded instead of elfboot.
>
> In normal bios, when booting Etherboot with ASK_BOOT, and using Q can 
> exit
> from Etherboot and back into BIOS, then can boot into HD and use HD
> bootloader.
>
> In LinuxBIOS, if LinuxBIOS is using elfboot to boot Etherboot elf, 
> when Q
> from Etherboot, should continue to do the code after elfboot. So may 
> put the
> filo after elfboot.
>
> But I think the best way is merged filo into Etherboot instead of 
> Linuxbios
> directly. Then We can use tg3-fs_stream.zelf or tg3_filo.zelf as 
> payload of
> LinuxBIOS.
>
> It is more better if filo support boot loader (lilo) in HD.
>
> Regards
>
> Yinghai Lu
>
> -----邮件原件-----
> 发件人: [e-mail]
> [mailto:[e-mail]] 代表 Eric W. Biederman
> 发送时间: 2004年4月3日 13:02
> 收件人: SONE Takeshi
> 抄送: [e-mail]
> 主题: Re: FILO 0.4
>
> SONE Takeshi  writes:
> > I just released FILO 0.4.
> > http://te.to/~ts1/filo/
> >
> > I'll work on config file support next time.
>
> Is this work still ongoing?  At first stab at a config
> file could hard code it's location like you currently do
> the kernel image.
>
> Another question listing files.  Currently you have that
> support completely removed from the Grub code.  Any thoughts
> on adding that.
>
> Eric
> _______________________________________________
> Linuxbios mailing list
> [e-mail]
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>
> Linuxbios mailing list
> [e-mail]
> http://www.clustermatic.org/mailman/listinfo/linuxbios

��: FILO 0.4 [PMX:#]

Greg Watson  writes:
> Yeah sorry, I kind of did that by stealth. Ron and I get lots of requests from
> people wanting to use LB but who don't know how to deal with the payload
> issue. We decided that it would be really nice to have a simple bootloader that
> understands some basic filesystems built into LB. That way people can get going
> without having to deal with etherboot or FILO directly. A nice side effect is
> that it simplifies the FILO code significantly - in fact the only code that is
> really required is the filesystem support. Also, another major plus is that the
> code supports PPC as well as x86. Up to now I've had no bootloaders (etherboot
> or FILO) that work on PPC.

Then we refactor and make building the bootloader part of the tree.
These things are policy engines.  We need to separate mechanism and policy.

As far as I can tell this level of support crosses the line.

etherboot is portable and would not be hard to get running on ppc.

Eric

ron minnich  writes:
> I was wondering about listing files. Once you add that, you add a command 
> interpreter, and that way lies madness.
>
> If, however, file listed all the files it found while attempting to load 
> an image, that might be enough.

What grub does is essentially tab completion in it's command line
editor.  Which is a bit peculiar but sane.

Eric

FILO 0.4 [PMX:#]

[Yinghai Lu]

I have checked the Etherboot, and it would be some easier to integrate filo
into Etherboot.

May add one BOOT_FILO in cmos.layout.

In the core/main.c, will judge if boot type is BOOT_FILO, and will call
filo, and set state still =4, so it can boot next device.

The problem is it is some kind of hard code. How can I enable tg3-filo.zelf?

Regards

YH.

-----邮件原件-----
发件人: Eric W. Biederman [mailto:[e-mail]] 代表 Eric W. Biederman
发送时间: 2004年4月3日 20:33
收件人: Greg Watson
抄送: Yinghai Lu; 'SONE Takeshi'; [e-mail]
主题: Re: g-e$: FILO 0.4 [PMX:#]

Greg Watson  writes:
> Yeah sorry, I kind of did that by stealth. Ron and I get lots of requests

from
> people wanting to use LB but who don't know how to deal with the payload
> issue. We decided that it would be really nice to have a simple bootloader

that
> understands some basic filesystems built into LB. That way people can get

going
> without having to deal with etherboot or FILO directly. A nice side effect

is
> that it simplifies the FILO code significantly - in fact the only code

that is
> really required is the filesystem support. Also, another major plus is

that the
> code supports PPC as well as x86. Up to now I've had no bootloaders

(etherboot
> or FILO) that work on PPC.

Then we refactor and make building the bootloader part of the tree.
These things are policy engines.  We need to separate mechanism and policy.

As far as I can tell this level of support crosses the line.

etherboot is portable and would not be hard to get running on ppc.

Eric

FILO 0.4 [PMX:#]

[Yinghai Lu]

Eric,

Greg just move the fs support from filo to linuxbios, and create fs_stream.

It still calls the elfboot to load the elfimage in HD. And it doesn't
support linux_load.

So it is some kind of boot loader you said.

It is really enhancement to ide_stream.c

Regards

YH

-----邮件原件-----
发件人: Eric W. Biederman [mailto:[e-mail]] 代表 Eric W. Biederman
发送时间: 2004年4月3日 20:33
收件人: Greg Watson
抄送: Yinghai Lu; 'SONE Takeshi'; [e-mail]
主题: Re: g-e$: FILO 0.4 [PMX:#]

Greg Watson  writes:
> Yeah sorry, I kind of did that by stealth. Ron and I get lots of requests

from
> people wanting to use LB but who don't know how to deal with the payload
> issue. We decided that it would be really nice to have a simple bootloader

that
> understands some basic filesystems built into LB. That way people can get

going
> without having to deal with etherboot or FILO directly. A nice side effect

is
> that it simplifies the FILO code significantly - in fact the only code

that is
> really required is the filesystem support. Also, another major plus is

that the
> code supports PPC as well as x86. Up to now I've had no bootloaders

(etherboot
> or FILO) that work on PPC.

Then we refactor and make building the bootloader part of the tree.
These things are policy engines.  We need to separate mechanism and policy.

As far as I can tell this level of support crosses the line.

etherboot is portable and would not be hard to get running on ppc.

Eric

FILO 0.4 [PMX:#]

[ron minnich]

On Sun, 4 Apr 2004, Yinghai Lu wrote:
> I have checked the Etherboot, and it would be some easier to integrate filo
> into Etherboot.

Not everyone here at LANL is that satisfied with etherboot, and in fact we
are moving over to FILO. There are a lot of reasons. We've just had lots 
better luck with FILO when all things are considered.

ron

FILO 0.4 [PMX:#]

ron minnich  writes:
> On Sun, 4 Apr 2004, Yinghai Lu wrote:
> > I have checked the Etherboot, and it would be some easier to integrate filo
> > into Etherboot.
>
> Not everyone here at LANL is that satisfied with etherboot, and in fact we
> are moving over to FILO. There are a lot of reasons. We've just had lots 
> better luck with FILO when all things are considered.

It's a good thing we have a choice then isn't it.  And this just
reinforces my certainty that none of these should be linked
into the LinuxBIOS core.

Personally the one I want is based on a real live kernel.  And if
I can get some time that is what you will see.

Eric

FILO 0.4 [PMX:#]

ron minnich  writes:
> On Sun, 4 Apr 2004, Yinghai Lu wrote:
> > I have checked the Etherboot, and it would be some easier to integrate filo
> > into Etherboot.
>
> Not everyone here at LANL is that satisfied with etherboot, and in fact we
> are moving over to FILO. There are a lot of reasons. We've just had lots 
> better luck with FILO when all things are considered.

Ron, is LANL going to maintain FILO then?

Unless I hear from SONE soon it is starting to look like like FILO is
unmaintained.

Has any one implemented config files?
Has any one implemented listing of files?

What do you do when you don't have a disk?

Eric

FILO 0.4 [PMX:#]

[ron minnich]

On 4 Apr 2004, Eric W. Biederman wrote:
> Personally the one I want is based on a real live kernel.  And if I can
> get some time that is what you will see.

Sure. That's where I started this project from almost 5 years ago. We only
have this plethora of bootloaders (etherboot, filo, 9load, etc.) because
our initial goals of a real live kernel proved techincally impossible --
flash was too small. 2.6 + bigger flashes might put us back where we were
4 years ago with the L440GX+ boards, with 1 MB flash and a 2.4.7 kernel
that easily fit in that space. We can hope so.

IIRC you and I had some discussion on this several years ago, on this
list, and you were firmly in the Etherboot camp, as you thought the small
fast Etherboot kernel had advantages over a full live Linux kernel. You
made some excellent arguments in favor of this idea. I argued that the
Etherboot approach was fundamentally flawed, and that in the end I wanted
a live kernel in there for booting. We agreed to disagree. So I'm glad to
have you back :-)

Just kidding. You and I both know the excellent Etherboot work you did was
a real accomplishment and definitely saved our collective necks.

But: you have to at some point consider what people are asking for, and we
do think about that as we get a lot of requests here not reflected to the
list.

Some ongoing requests: VGA that works in linuxbios, and a boot prompt that
can allow a user to type a pathname to a CD image and do an install. One
build, not two or three. And people want it in one package.  The
requirement with the current setup to build multiple binaries such as
Etherboot at present can't do this. Greg's test integrated FILO can. We
also need the emulator in linuxbios because that is the only practical way
to get to this demand. And it's got to be very very small. Some of the 
recent changes in V2 have been tough on the embedded folks, and that is of 
real concern to us. Please bear in mind that you folks at LNXI are not as 
affected by the embedded world as we are down here, and I have had a 
number of comments about V2 in that regard.

Hence these trial changes. Plus, a simple fact: if you don't like them, 
don't enable them. Nobody's locking them in. We are making them available 
to those who can use them. The goal is flexibility.

We've also had lots of people with issues with the ELF loader approach.  
Requiring an ELF target is requiring a policy as near as I can tell.  
Many people don't want to deal with mkelfImage, esp. as it has proven to
be non-portable in some cases (maybe this can be fixed, but if you
mkelfImage on a 64-bit K8, etherboot coughs and dies in the elf loader 
-- there are issues).

Also, re this: "In addition we have had way to many questions of what is
the right policy for a bootloader to implement, on this list.  I refuse to
couple that to the LinuxBIOS core.  And I don't want some stupid policy in
there like FILO's that would require me to upgrade my firmware just to
upgrade my OS.  "

To most people, the distinction between "payload in flash" and "linuxbios 
in flash" is immaterial. In other words, these folks don't care about the 
seperation between LinuxBIOS and payload! they are much happier with an 
integrated one-step system that boots an OS. What they want is to be able 
to install from CD. Etherboot won't let them do this, and neither will an 
ELF loader. Integrated Filo gives people something they can use today, 
that will be easy to build.

Finally, let's remember that the ultimate goal of a project such as
LinuxBIOS is utility, not beauty and beauty alone. Sometimes what some
people consider beautiful is sacrificed in order to support needs of
customers. Let's not go so far into concern for beauty that we forget that
lesson. I'm maxed out on 'beauty uber alles' on the Plan 9 list.

Anyway, before this conversation gets too hot, please everyone take a deep 
breath, remember your email etiquette, and don't forget we are all friends 
here. It's important to resolve these issues in an atmosphere of 
cordiality.

ron

FILO 0.4 [PMX:#]

[ron minnich]

On 4 Apr 2004, Eric W. Biederman wrote:
> Ron, is LANL going to maintain FILO then?

Right now, LANL doesn't by itself maintain everything any way. Look at the 
excellent work you and Yinghai and others do every day on LinuxBIOS.
> Unless I hear from SONE soon it is starting to look like like FILO is
> unmaintained.

If there is interest in FILO, then I expect we'll have good people (like 
you, but obviously not you :0) ) to help out.
> Has any one implemented config files?

not sure what you mean.
> Has any one implemented listing of files?

not yet.
> What do you do when you don't have a disk?

For the communities which need FILO, this is not a concern.

ron

FILO 0.4 [PMX:#]

[ron minnich]

RE the bigger issue of compiling things direct into linuxbios.

I've been thinking for some time of an experiment, namely turning this 
whole business inside-out. Think of it this way: there is a runtime 
startup for every program your write, called in old times crt0 (which is 
why I used that name for LinuxBIOS). But from your point of view, your 
program is not crt0, it's main().

So looking from the point of view of the compiler and library writers, who 
know nothing of your program when they write the compilers and libraries, 
the world is libc.a and crt0. You don't care about that, and from your 
point of view, the world is your program. You use the compiler to get your 
startup code and some library calls.

This leads to a natural question: what if we think of linuxbios as
something to be linked into a boot loader such as openbios, filo, 9load,
or even a special linux kernel? In other words, invert our view of the
world: we don't compile a boot loader as part of building linuxbios; we
compile linuxbios into a bootloader. Linuxbios provides startup (analogous
to crt0) and some library functions the boot loader needs (print* support,
pci enumeration, etc) but the really important bit is the boot loader.

In this view, linuxbios is a library that you link your bootloader with to
build a bios. This really changes things around a bit. It also removes 
some nasty problems, as the bootloader no longer has to supply (e.g.) its 
own PCI enumeration code, and can use the linuxbios PCI enumeration code, 
which can help boot loaders avoid bugs in chips (consider the VT8601 and 
the PCI bugs it used to have).

This view is sort of halfway from old bios ideas (INT xy) and current
ideas (the payload doesn't know linuxbios exists). It's a huge change --
maybe a very bad idea, as it means that now LinuxBIOS provides an API,
which we never intended it to do. I have no idea if it even makes sense --
just wondering.

Back to our irregularly scheduled arguments :-)

ron

FILO 0.4 [PMX:#]

[Hendricks David W.]

I've got one word for ya Ron: .ebuild

Just kidding :) (Or am I?)

On Sun, 4 Apr 2004, ron minnich wrote:
> One build, not two or three. And people want it in one package.

FILO 0.4 [PMX:#]

ron minnich  writes:
> RE the bigger issue of compiling things direct into linuxbios.
>
> I've been thinking for some time of an experiment, namely turning this 
> whole business inside-out. Think of it this way: there is a runtime 
> startup for every program your write, called in old times crt0 (which is 
> why I used that name for LinuxBIOS). But from your point of view, your 
> program is not crt0, it's main().
>
> So looking from the point of view of the compiler and library writers, who 
> know nothing of your program when they write the compilers and libraries, 
> the world is libc.a and crt0. You don't care about that, and from your 
> point of view, the world is your program. You use the compiler to get your 
> startup code and some library calls.
>
> This leads to a natural question: what if we think of linuxbios as
> something to be linked into a boot loader such as openbios, filo, 9load,
> or even a special linux kernel? In other words, invert our view of the
> world: we don't compile a boot loader as part of building linuxbios; we
> compile linuxbios into a bootloader. Linuxbios provides startup (analogous
> to crt0) and some library functions the boot loader needs (print* support,
> pci enumeration, etc) but the really important bit is the boot loader.
>
> In this view, linuxbios is a library that you link your bootloader with to
> build a bios. This really changes things around a bit. It also removes 
> some nasty problems, as the bootloader no longer has to supply (e.g.) its 
> own PCI enumeration code, and can use the linuxbios PCI enumeration code, 
> which can help boot loaders avoid bugs in chips (consider the VT8601 and 
> the PCI bugs it used to have).

The amount of code we are talking about there is about a 1000 lines 
(at least on x86), and can easily be shared by cut and paste.  I would
be surprised if PPC and other architectures were worse, but they may be.

As for avoiding bugs, the solution is to dump our device tree via the
LinuxBIOS table.  That is on the TODO list.  It has not been a big
enough problem for anyone to care about implementing it yet.
> This view is sort of halfway from old bios ideas (INT xy) and current
> ideas (the payload doesn't know linuxbios exists). It's a huge change --
> maybe a very bad idea, as it means that now LinuxBIOS provides an API,
> which we never intended it to do. I have no idea if it even makes sense --
> just wondering.

Yes this is how you implement a bad imitation of an OS.

First you start adding functions that the core LinuxBIOS code cares
nothing about so they are poorly maintained.

Then you turn into a shared library so multiple programs running
on the system can call you.

Then you implement support for binary plugin options roms.

You have to write multiple versions of your code for: 8, 16, 32, 64,
and 128 bit processor modes.  And they have to all cooperate nicely.

Basically you do what everyone has always done before and resulted
in a big maintenance nightmare.  I refuse to even consider maintaining
that.

I am really only interested only interested in supporting free-standing
programs.
> Back to our irregularly scheduled arguments :-)

Eric

FILO 0.4 [PMX:#]

[ron minnich]

On Mon, 5 Apr 2004, Hendricks David W. wrote:
> I've got one word for ya Ron: .ebuild

ARGARGARG. You're kidding.

ron

FILO 0.4 [PMX:#]

[ron minnich]

On 5 Apr 2004, Eric W. Biederman wrote:
> (some good points). 
> I am really only interested only interested in supporting free-standing
> programs.

Yeah, I think I share your interest. Having a BIOS with an API could be a
can of worms.

Back to our regularly scheduled discussion.

ron

FILO 0.4 [PMX:#]

[ron minnich]

On Tue, 6 Apr 2004, ron minnich wrote:
> On 5 Apr 2004, Eric W. Biederman wrote:
> > (some good points). 
> > I am really only interested only interested in supporting free-standing
> > programs.
>
> Yeah, I think I share your interest. Having a BIOS with an API could be a
> can of worms.

actually, I should say, from 5 years ago, that the planned API for the 
BIOS was ... Linux.

Sigh, I keep forgetting. Sorry.

ron