On Friday 07 December 2007, Otavio Salvador wrote: > > In fact, as to Otavio's point, it probably makes sense to do the > > module loading outside of hw-detect (e.g. his acpi-support-udeb > > suggestion), and just let hw-detect use the interface if its > > available. > > Yes, I think it's starting to makes sense to have something like that > and put all this in one cannonical place. Does someone objects if I > start to prepare this udeb for review?
I still don't see this. If that means that udeb is going to be part of initrds, I don't see why it should be separate from hw-detect. Or is Otavio referring to to a separate kernel udeb? In that case again, if it is going to be part of the initrd, why not just add it to the existing acpi-modules udeb. For Otavio's usage (laptop detection), it does not _need_ to be part of the initrd and then a separate modules udeb could make sense, but it still could be loaded in hw-detect as we always have at least one hw-detect run after additional udebs have been loaded. For Dann's usage however, IMO it would really need to be part of the initrd to ensure that we have consistent functionality between installation methods, so creating separate udebs for it makes absolutely no sense. And then we come back to my earlier question: is being able to show slot info worth increasing the size of initrds and memory usage because the acpi module is loaded. Note that every udeb that is added also brings its own overhead!
signature.asc
Description: This is a digitally signed message part.
