On Mon, Mar 23, 2009 at 08:33:45AM +0100, Pierre Bourgin wrote:
>
> That's what I was thinking about while talking about "cache file" ... My
> explanations were not probably as lighting as yours ;-)
>
> Notice that It won't be a hash indexed by INF strings, but an array, since
> several drivers may match a given INF string.
Probably what I was really thinking at the time was that it would be a hash of
lists. The reason for the hash is that
then we can use the optimized perl hash lookup rather than scanning through the
entire array. It also makes the
resulting code slightly shorter.
> To reduce the memory footprint, may use grep() function of perl on index as
> falt ascii content ? But It will costs more I/O and time, since we have to
> parse the index file for each INF strings (corresponding to PCI/HDAUDIO/USB
> devices).
I don't think that you have to worry about the memory footprint of this scan
driver program. We can probably assume
that we'll have enough memory to run Windows. I don't think that the list of
drivers is really that big in comparison.
> Which format would you recommend for index file ? a simple text (ascii)
> file, or a dump of perl datas/structure serialized (thus "binary" content) ?
Flat text file with the lookup key and driver path on one line. It also makes
debugging easier.
> Keep in mind that such an index file may be generated by any perl version,
> since generated by the system that hosts the Windows driver files for
> instance: perl dump of datas are portable across perl versions ?
That is why the flat text file.
> This other point for me is that search-win-drivers.pl has to be able to
> deal with several drivers path, like win_drivers/DriverPacks/ and
> win_drivers/my_specific_stuff/ instead of (only) win_drivers/ : this will help
> people to (re)generate more quickly indexes, since we can bet that content
> of win_drivers/DriverPacks/ does not change so quickly, compared to
> win_drivers/my_specific_stuff/ .
What about supporting multiple index files? Then reading the indices is just
reading multiple index files and adding
them to the internal "lookup table." If you use something that works like sets
then you don't have to worry about exact
duplicates either. I don't think perl has "sets" so you can use something like
a hash of hashes.
For example, to read the index files, do something like this for each index
file;
while (<>) {
($a, $b) = split(/:/, $_); # split on whatever separates the key from the
driver path
if (! exists $drivers{$a}) {
$drivers{$a} = {};
};
$drivers{$a}{$b} = 1;
};
Then, to get the list of drivers for a given key:
if (exists $drivers{$key}) {
print keys($drivers{$key});
};
I'm not that good with perl, so you will likely have to fix the above syntax a
bit, but I think the ideas are there.
Allan.
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
unattended-devel mailing list
unattended-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unattended-devel
