On Mon, 2009-06-08 at 14:24 -0400, Bill McGonigle wrote: > On 06/08/2009 01:30 PM, Adam Williamson wrote: > > Fedora intentionally doesn't have one, as it duplicates work done by > > X.org (device / driver detection is done in the X server). > > So, how do we get this info to anaconda, such that we can avoid breaking > users' setups? In my case, the X driver for radeon could have > conceivably told anaconda that it was not going to help, but then > anaconda would have had to know to go to ask the other radeon driver. I > suppose per-manufacturer there aren't that many to try. Your question doesn't quite make sense in context... take a look at hw/xfree86/common/xf86AutoConfig.c in the X server source. That's where autodetection is done, you can see how it works. Basically, ranges of PCI IDs, or single IDs, are mapped to specific drivers. If the hardware doesn't match any of the mappings, it falls back to the generic set of drivers, so usually it winds up using vesa. Usually how it works is that an entire manufacturer ID is mapped to a driver. So, for nvidia cards, the 0x10DE manufacturer ID is mapped to the nouveau driver, so any card with the 0x10DE manufacturer ID (all modern NVIDIA-based cards use it) gets the nouveau driver - except that a few IDs are special-cased and explicitly mapped to nv or vesa instead. I haven't actually looked at what it does for ATI cards, but likely it does much the same: the entire ATI manufacturer ID is mapped to 'radeon'. If you knew of cards that simply didn't work with the driver, they could be mapped to 'vesa' as exceptions. anaconda doesn't have to do anything. Anaconda uses a perfectly standard X, so it gets the same autodetected driver as an installed system would. > Then there needs to be a way to iterate this process for sound cards, > NIC's, storage, etc. e.g. a while back a SCSI controller I used moved > from megaraid to megaraid-legacy or something along those lines. I > realize most of these device ID's are available in .h files, but AFAIK, > there's not yet a uniform way to query/compile/extract them. It might > be possible to define a set of transforms for each category, and only > compile an install-time database at build time. Kernel level hardware autodetection is done via modaliases, which is actually a very elegant system. In the past, distros - including Red Hat - had a big database of the kind you're imagining that mapped IDs to modules and turned them into /etc/modules files during the install process and had to be manually updated and was generally a nightmare. I can give you more details on how modaliases work if you like, but basically the device->module mappings are now carried in the modules themselves; the modules specify which devices they support, and the module gets loaded on that hardware automatically just using that system. No distro-level infrastructure is needed. > Then there's the further problem of which driver options are stable per > hardware device. e.g. in X, acceleration types, opengl settings, etc. > But maybe the right thing is to just build in the correct defaults into > the driver. Yes, that's it. > But then determining which defaults are correct across the > myriad devices developers don't have is another problem, but one > something like smolt could also address. Indeed, though we're not quite there yet. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
