> [First we need to be able to reach _one_ supplementary source of data :
> Network in this case, but this can be local disks too]
> - GRUB as a bootloader
Neat idea, using grub to choose modules.
>
> -------------------------
>
> These informations are spread (in the Linux kernel sources) in the drivers
> sources. For example, in the drivers/net directory, we take 3c59x.c :
For debian-installer we used /usr/share/detect/pci.list from the libdetect0
package, FWIW.
> for every driver of a pci type of card :
> for every vendorId and DeviceID
> add vendorID:DeviceID\tDRV_NAME to the database
>
> An optimization will be to create database from classes of devices in order
> to allow the use of smallest databases.
good way of reducing the amount of information.
>
> What would be great too is to have a central place (there is
> http://www.yourvote.com/pci/ for the IDs to name mapping; one can know other
> db) to add the informations about PCI devices and drivers (one Debian db
> accessible via network for example).
>
>
> RFC
When we did pci hardware detection for d-i we used straight libdetect. It
is missing some of the space optimizations that you have in here, but
avoids the 're-inventing the wheel' problem. What is you feeling on ISA
hardware? support it/don't?
I'm starting to work on d-i again, but all I really want is a next
generation installer for Debian, and if it works for other OS's as well
that would be a big bonus. I hope we can combine efforts, maybe even
projects.
This idea for d-i is that the first disk (i386 only at the moment) does
hardware detection of ethernet modules. After that the rest of the
installer is downloaded over the ethernet and the installer can proceed
with partitioning, base install, etc.
-David
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
