(Good discussion so far, sorry for the late response..) On Sunday 09 December 2007, Frans Pop wrote: > On Friday 07 December 2007, dann frazier wrote: > > Understood. Note that this implementation doesn't *require* the > > module, it just takes advantage of it if its available. And, if > > other > > non-ACPI platforms begin populating the 'slot' sysfs field in the > > future, the installer would automatically work with it. > > Sure, but what use is it to implement it if we're not going to > actually use it? Adding support for it IMO also means adding any > modules needed to display the info (for platforms that support it of > course).
My implication is that any installer builds that happen to include the appropriate acpi modules could use this functionality. However, I see you state elsewhere: On Sunday 09 December 2007, Frans Pop wrote: > 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, If consistency between install methods is a goal, then my note above isn't relevant... at least not while slot info requires additional modules. > Could you provide some data on what it would cost to add this module > to initrds? Needed is total of extra memory used because of increased > initrd size the module(s) getting loaded. Ideally we could do this experiment on i386 since its the only architecture I would expect to have ACPI and have tight memory requirements. Unfortunately, I don't have an i386 system that supports the acpiphp module - my systems only support cpqphp and acpiphp refuses to load if the system does not support it. However, if we can make the assumption that memory pressure isn't an issue on systems that support ACPI PCI HotPlug, then the memory lost to module load isn't significant[1]. I compared a standard build of the netboot/i386 flavor, and one where the acpiphp module were added to the acpi-modules udeb. acpiphp depends upon the pci_hotplug and dock modules, so they are also included. build initrd.gz size used memory ------------------------------------------------ standard 5005534 23864 w/ acpiphp 5031680 24176 [1] Of course, acpiphp has module dependencies, and if these aren't cleaned up after a failed load, memory will still be lost to those modules Joey Hess wrote: > Frans Pop wrote: > > > eth0: foo bar description, eth0: mac address: xxx:xxx... [slot 1] > > > > > > That would be one way to do it without modifying debconf. You > > could also > > > get rid of the "eth0: " prefix if you wanted to by using > > Choices-C. > > > > I'm probably just being thick, but what exactly are you proposing > > here? > > Debconf would display the above example as: > > eth0: foo bar description > eth0: mac address: xxx:xxx... [slot 1] I like this idea, and Frans' suggestion to indent instead of duplicating the interface name would make it looks pretty nice. I can't think of any better way to do it w/o extending debconf. If noone has any major objections, I'll see if I can work up a patch. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]