Hi, > At what point do we reexamine everything that is done in driver discs > in > terms of what is absolutely required, versus 'what we have always > done'? > > For example, the 'feature' of unloading all drivers to then load them > in an > interactive order seems to mainly be there to preserve the fallacy > that > storage device names are meaningful. Is that the only reason that > it's > required? If so, is that feature worth an entirely separate > interactive > infrastructure? Why does it need to be interactive, when it could > theoretically be done via kickstart commands, or commandline > operations? This is not part of the driver disc infrastructure as I know it. Driver discs can be noninteractive - with the exception of the features I talked about. Manual driver _disc_ (not single driver) selection and automatically detected driver disc confirmation (and at least the second one is a must). It is not about what we have always done, but more about what the customers expect to still work. It takes a lot of politics to convince them that they do not need a feature they have always used :) I see the points in moving it to anaconda directly, but I also see what becomes hard to do in the use cases when dracut is not able to load the whole big image, either because the hw/fw limits it (PPC) or because it is stored somewhere we do not have access to. Those might be uncommon, but this feature was never meant for the common user, it is used by couple of big vendors with exactly this sort of problems. One use case we ran into was to select one driverdisc from a media to get access to a device with a second one that contained drivers for all hardware the vendor supported. It allowed them to maintain only one big image.. If we can ensure that dracut always gets install.img, regardless on the install method and the novelty of used hardware, then we can move this feature to anaconda. If not, it has to go to dracut (and will probably use question/answer by number system). Martin _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
