I've just finished fixups to filo that make it quite a bit faster. First, it used to scan the bus twice, the first time to do a count. That's slow, although it was a nice algorithm. But it only needed to find at most 2 devices. Now it scans until the device is found and returns it. Even in the worst case, the new pci scan is always faster than the old. There are new options in addition to PCI_BRUTE_SCAN. PCI_BRUTE_SCAN means: scan everything ... PCI_BRUTE_SCAN_START ... but start at this bus (VERY good on k8, as the scan of 0:19.* takes FOREVER). PCI_BRUTE_SCAN_LIMIT = 2 ... and end here -1(useful when you know that the busses don't range to 256) And the 'instant gratification' option: IDE_HINT_BUS IDE_HINT_DEV IDE_HINT_FUNC All three must be set or not set or you get a compile-time warning. IF all three are set, FILO will probe the device and IF it is an ide controller use that. If it's not an ide controller, filo will scan busses as usual. This last option REALLY speeds things up ron
On Fri, 2004-10-29 at 15:59, Ronald G. Minnich wrote:
I've just finished fixups to filo that make it quite a bit faster.
First, it used to scan the bus twice, the first time to do a count. That's slow, although it was a nice algorithm. But it only needed to find at most 2 devices.
Since it appears nobody is maintaining FILO do you think we should put it in util directory in freebios2? Ollie
On Fri, 29 Oct 2004, Li-Ta Lo wrote:
Since it appears nobody is maintaining FILO do you think we should put it in util directory in freebios2?
that's my plan. ron
"Ronald G. Minnich" <rminnich@lanl.gov> writes:
On Fri, 29 Oct 2004, Li-Ta Lo wrote:
Since it appears nobody is maintaining FILO do you think we should put it in util directory in freebios2?
that's my plan.
Please let's give it's own namespace, just like freebios2 has. Or at least could we start a util tree for these kinds of things. I'd like to keep the parts that are independent of the LinuxBIOS revision a little separate so if we ever need to do something like the freebios2 tree again they can happily live again. Romcc and config.g and one or two other utilities are tightly tied to the LinuxBIOS revisions so the make a lot of sense. Eric
On Fri, 2004-10-29 at 16:53, Eric W. Biederman wrote:
"Ronald G. Minnich" <rminnich@lanl.gov> writes:
On Fri, 29 Oct 2004, Li-Ta Lo wrote:
Since it appears nobody is maintaining FILO do you think we should put it in util directory in freebios2?
that's my plan.
Please let's give it's own namespace, just like freebios2 has. Or at least could we start a util tree for these kinds of things.
I'd like to keep the parts that are independent of the LinuxBIOS revision a little separate so if we ever need to do something like the freebios2 tree again they can happily live again.
Romcc and config.g and one or two other utilities are tightly tied to the LinuxBIOS revisions so the make a lot of sense.
I think we should move most of the utils into its own util package. The config tool should be move to a new directory call "tools" in freebios2. Ollie
Li-Ta Lo <ollie@lanl.gov> writes:
I think we should move most of the utils into its own util package. The config tool should be move to a new directory call "tools" in freebios2.
Sounds good. tools/utils I don't care, so long as the separate package has it's own top level directory in cvs. Eric
* Eric W. Biederman <ebiederman@lnxi.com> [041030 00:53]:
Please let's give it's own namespace, just like freebios2 has. Or at least could we start a util tree for these kinds of things.
That's what the util/extensions was intended for. Stefan
On Fri, 29 Oct 2004, Eric W. Biederman wrote:
Please let's give it's own namespace, just like freebios2 has. Or at least could we start a util tree for these kinds of things.
that's my plan9. I'm considering this: freebios2/payloads for payloads like filo that are part of the tree. ron
On Fri, 29 Oct 2004, Ronald G. Minnich wrote:
This last option REALLY speeds things up
linux is running in < 8 seconds. 3 of those seconds are FILO waiting for me to type return or not. This is an arima hdama. Having the payload skip the bus probe is a win. Of course, in the long term, we want all payloads reading the linuxbios table for pci bus, but this hack will do for now. ron
participants (4)
-
ebiederman＠lnxi.com -
Li-Ta Lo -
Ronald G. Minnich -
Stefan Reinauer