On Fri, 12 Sep 2008 05:21:08 +0200, Peter Stuge peter@stuge.se wrote:
Joseph Smith wrote:
FILO searches for a filo.conf file on the first drive it finds
Scanning for drives has been considered before but always dismissed because it will potentially take a very long time for FILO to start if it needs to wait for drives to start.
Doesn't the drive have to start for FILO to invoke GRUB?
As an optional feature, everyone pretty much said they want to be able to do such a drive scan only a few days ago. Would be great if you want to hack on it! :)
I do think this would be better approach. I don't think scanning a top level directory would take very long. It wouldn't scan sub directories. Especially when the first drive it finds in the first partition root directory is usually your "/boot" partition. How many files are there, not many.
Joseph Smith wrote:
Scanning for drives has been considered before but always dismissed because it will potentially take a very long time for FILO to start if it needs to wait for drives to start.
Doesn't the drive have to start for FILO to invoke GRUB?
FILO never invokes GRUB. FILO has it's own code that implements GRUB-like functionality.
Yes, _the specified drive_ has to start before FILO can read from it.
But not _every drive_ needs to be checked, because the correct device has to be specified beforehand.
As an optional feature, everyone pretty much said they want to be able to do such a drive scan only a few days ago. Would be great if you want to hack on it! :)
I do think this would be better approach. I don't think scanning a top level directory would take very long.
The issue is not with filesystem structure. The issue is with drives. Scanning drives takes some time, at least a few seconds per drive or so.
Once the correct drive has been found, finding the boot files is usually quick because only few sectors needs to be read.
//Peter
On Fri, Sep 12, 2008 at 5:43 AM, Peter Stuge peter@stuge.se wrote:
As an optional feature, everyone pretty much said they want to be able to do such a drive scan only a few days ago. Would be great if you want to hack on it! :)
I do think this would be better approach. I don't think scanning a top level directory would take very long.
Yes, a command in filo to scan for drives and report what he found would be a great enhancement. I'll certainly test patches that try to achieve this.
The issue is not with filesystem structure. The issue is with drives. Scanning drives takes some time, at least a few seconds per drive or so.
If this is implemented as a command, and not part of default filo startup that would be fine, scanning has to be started by user interactively.
Once the correct drive has been found, finding the boot files is usually quick because only few sectors needs to be read.
Yeah, the hard part is finding which "string" to give filo as drive name, the file name is often already known. Not that I wouldn't want the "find" command get an implementation that do something, tho...
On Fri, 12 Sep 2008 11:20:04 +0200, "Vincent Legoll" vincent.legoll@gmail.com wrote:
On Fri, Sep 12, 2008 at 5:43 AM, Peter Stuge peter@stuge.se wrote:
As an optional feature, everyone pretty much said they want to be able to do such a drive scan only a few days ago. Would be great if you want to hack on it! :)
I do think this would be better approach. I don't think scanning a top level directory would take very long.
Yes, a command in filo to scan for drives and report what he found would be a great enhancement. I'll certainly test patches that try to achieve this.
The issue is not with filesystem structure. The issue is with drives. Scanning drives takes some time, at least a few seconds per drive or so.
If this is implemented as a command, and not part of default filo startup that would be fine, scanning has to be started by user interactively.
Once the correct drive has been found, finding the boot files is usually quick because only few sectors needs to be read.
Yeah, the hard part is finding which "string" to give filo as drive name, the file name is often already known. Not that I wouldn't want the "find" command get an implementation that do something, tho...
I think the find command would ulimatly become a part of libpayload so it could be used for something like coreinfo?? I think the ata/ide drivers from FILO would have to be moved to libpayload for coreinfo also. But, it would be cool to have coreinfo tell you info about your drives :-)
I think for FILO, we would only care about finding the filo.conf file.
On 12/09/08 08:15 -0400, Joseph Smith wrote:
On Fri, 12 Sep 2008 11:20:04 +0200, "Vincent Legoll" vincent.legoll@gmail.com wrote:
On Fri, Sep 12, 2008 at 5:43 AM, Peter Stuge peter@stuge.se wrote:
As an optional feature, everyone pretty much said they want to be able to do such a drive scan only a few days ago. Would be great if you want to hack on it! :)
I do think this would be better approach. I don't think scanning a top level directory would take very long.
Yes, a command in filo to scan for drives and report what he found would be a great enhancement. I'll certainly test patches that try to achieve this.
The issue is not with filesystem structure. The issue is with drives. Scanning drives takes some time, at least a few seconds per drive or so.
If this is implemented as a command, and not part of default filo startup that would be fine, scanning has to be started by user interactively.
Once the correct drive has been found, finding the boot files is usually quick because only few sectors needs to be read.
Yeah, the hard part is finding which "string" to give filo as drive name, the file name is often already known. Not that I wouldn't want the "find" command get an implementation that do something, tho...
I think the find command would ulimatly become a part of libpayload so it could be used for something like coreinfo?? I think the ata/ide drivers from FILO would have to be moved to libpayload for coreinfo also. But, it would be cool to have coreinfo tell you info about your drives :-)
Having the drive drivers in libpayload is still a matter of some debate. When we started, we agreed that we wouldn't try to re-invent the world - we already had excellent bootloaders that did drives (GRUB2) and network (gPXE). Now, we are trending away from GRUB2, and we maintain our own ATA drivers anyway in FILO, so our original premise is in doubt.
Unfortunately if we decide we want ATA drivers in libpayload, we can't borrow them from FILO because of licensing issues, we would have to write them ourselves, or borrow them from a BSD source.
-
Jordan Crouse -
Joseph Smith -
Peter Stuge -
Vincent Legoll