[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#454493: Display PCI slot for nics, if available



(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




Reply to: