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 <lly@pisem.net>. The filesystem code was originally written by Kousuke Takai <tak@kmc.gr.jp> 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. -- Takeshi
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 -- Andrew Ip Email: aip@cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. For public pgp key, please obtain it from http://www.keyserver.net/en.
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.. -- Takeshi
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 <ts1@tsn.or.jp> 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
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 -----邮件原件----- 发件人: linuxbios-admin@clustermatic.org [mailto:linuxbios-admin@clustermatic.org] 代表 Eric W. Biederman 发送时间: 2004年4月3日 13:02 收件人: SONE Takeshi 抄送: linuxbios@clustermatic.org 主题: Re: FILO 0.4 SONE Takeshi <ts1@tsn.or.jp> 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 Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
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
-----邮件原件----- 发件人: linuxbios-admin@clustermatic.org [mailto:linuxbios-admin@clustermatic.org] 代表 Eric W. Biederman 发送时间: 2004年4月3日 13:02 收件人: SONE Takeshi 抄送: linuxbios@clustermatic.org 主题: Re: FILO 0.4
SONE Takeshi <ts1@tsn.or.jp> 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 Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
_______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
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:gwatson@lanl.gov] 发送时间: 2004年4月3日 17:29 收件人: Yinghai Lu 抄送: 'SONE Takeshi'; 'Eric W. Biederman'; linuxbios@clustermatic.org 主题: 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
-----邮件原件----- 发件人: linuxbios-admin@clustermatic.org [mailto:linuxbios-admin@clustermatic.org] 代表 Eric W. Biederman 发送时间: 2004年4月3日 13:02 收件人: SONE Takeshi 抄送: linuxbios@clustermatic.org 主题: Re: FILO 0.4
SONE Takeshi <ts1@tsn.or.jp> 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 Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
_______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Greg Watson <gwatson@lanl.gov> 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
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:eric@lnxi.com] 代表 Eric W. Biederman 发送时间: 2004年4月3日 20:33 收件人: Greg Watson 抄送: Yinghai Lu; 'SONE Takeshi'; linuxbios@clustermatic.org 主题: Re: g-e$: FILO 0.4 [PMX:#] Greg Watson <gwatson@lanl.gov> 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
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
ron minnich <rminnich@lanl.gov> 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
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
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.
On Mon, 5 Apr 2004, Hendricks David W. wrote:
I've got one word for ya Ron: .ebuild
ARGARGARG. You're kidding. ron
ron minnich <rminnich@lanl.gov> 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
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
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
ron minnich <rminnich@lanl.gov> 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
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
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
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:eric@lnxi.com] 代表 Eric W. Biederman 发送时间: 2004年4月3日 20:33 收件人: Greg Watson 抄送: Yinghai Lu; 'SONE Takeshi'; linuxbios@clustermatic.org 主题: Re: g-e$: FILO 0.4 [PMX:#] Greg Watson <gwatson@lanl.gov> 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
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
ron minnich <rminnich@lanl.gov> 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
participants (8)
-
Andrew Ip -
ebiederman＠lnxi.com -
Greg Watson -
Hendricks David W. -
ron minnich -
Ronald G. Minnich
-
SONE Takeshi -
Yinghai Lu