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

This is a discussion on Bug#454493: Display PCI slot for nics, if available - Debian ; (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 ...

+ Reply to Thread
Results 1 to 8 of 8

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

  1. 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




    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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

    dann frazier writes:

    > [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


    It means that we'd need to find a way to get those dependencies and
    walk throught them removing the unused ones.

    --
    O T A V I O S A L V A D O R
    ---------------------------------------------
    E-mail: otavio@debian.org UIN: 5906116
    GNU/Linux User: 239058 GPG ID: 49A5F855
    Home Page: http://otavio.ossystems.com.br
    ---------------------------------------------
    "Microsoft sells you Windows ... Linux gives
    you the whole house."



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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

    On Thu, Dec 27, 2007 at 05:09:38PM -0200, Otavio Salvador wrote:
    > dann frazier writes:
    >
    > > [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

    >
    > It means that we'd need to find a way to get those dependencies and
    > walk throught them removing the unused ones.


    Yeah. Options here would be:
    1) big hammer - write a modprobe wrapper that cleans
    unused/unloadable modules after every load
    2) smaller hammer - write a modprobe wrapper that remembers what was
    loaded before and, on failure, unloads all newly added, unused,
    unloadable modules
    3) surgical hammer - whatever ends up loading acpihpi knows that, on
    failure, dock and pci_hotplug should be removed (if unused)

    fyi, the dependencies loaded, and left unused, eat 9476 (dock) and
    28600 (pci_hotplug) bytes.

    --
    dann frazier




    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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

    dann frazier writes:

    > On Thu, Dec 27, 2007 at 05:09:38PM -0200, Otavio Salvador wrote:
    >> dann frazier writes:
    >>
    >> > [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

    >>
    >> It means that we'd need to find a way to get those dependencies and
    >> walk throught them removing the unused ones.

    >
    > Yeah. Options here would be:
    > 1) big hammer - write a modprobe wrapper that cleans
    > unused/unloadable modules after every load
    > 2) smaller hammer - write a modprobe wrapper that remembers what was
    > loaded before and, on failure, unloads all newly added, unused,
    > unloadable modules
    > 3) surgical hammer - whatever ends up loading acpihpi knows that, on
    > failure, dock and pci_hotplug should be removed (if unused)
    >
    > fyi, the dependencies loaded, and left unused, eat 9476 (dock) and
    > 28600 (pci_hotplug) bytes.


    imo, the best and more widly solution would be the 2. That shouldn't
    be too hard and would allow us to reduce the memory footprint not only
    on your user case but in general usage too.

    --
    O T A V I O S A L V A D O R
    ---------------------------------------------
    E-mail: otavio@debian.org UIN: 5906116
    GNU/Linux User: 239058 GPG ID: 49A5F855
    Home Page: http://otavio.ossystems.com.br
    ---------------------------------------------
    "Microsoft sells you Windows ... Linux gives
    you the whole house."



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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

    On Thu, Dec 27, 2007 at 07:15:01PM -0200, Otavio Salvador wrote:
    > dann frazier writes:
    > > Yeah. Options here would be:
    > > 1) big hammer - write a modprobe wrapper that cleans
    > > unused/unloadable modules after every load
    > > 2) smaller hammer - write a modprobe wrapper that remembers what was
    > > loaded before and, on failure, unloads all newly added, unused,
    > > unloadable modules
    > > 3) surgical hammer - whatever ends up loading acpihpi knows that, on
    > > failure, dock and pci_hotplug should be removed (if unused)
    > >
    > > fyi, the dependencies loaded, and left unused, eat 9476 (dock) and
    > > 28600 (pci_hotplug) bytes.

    >
    > imo, the best and more widly solution would be the 2. That shouldn't
    > be too hard and would allow us to reduce the memory footprint not only
    > on your user case but in general usage too.


    Might be vearing off topic for this bug, but here's a wrapper I worked
    up (not yet tested in the d-i environment).

    --
    dann frazier



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

    dann frazier writes:

    >> imo, the best and more widly solution would be the 2. That shouldn't
    >> be too hard and would allow us to reduce the memory footprint not only
    >> on your user case but in general usage too.

    >
    > Might be vearing off topic for this bug, but here's a wrapper I worked
    > up (not yet tested in the d-i environment).


    It looks nice.

    I think that code might be more clear if you change the cleanup step
    to be a funtion and it will make simpler to spot what is being done in
    each case.

    I see no point in using aggresive policy. It would unload the modules
    detected by udev and since we provide a small set of modules it looks
    useless to me. Do you see any possible usage?

    --
    O T A V I O S A L V A D O R
    ---------------------------------------------
    E-mail: otavio@debian.org UIN: 5906116
    GNU/Linux User: 239058 GPG ID: 49A5F855
    Home Page: http://otavio.ossystems.com.br
    ---------------------------------------------
    "Microsoft sells you Windows ... Linux gives
    you the whole house."



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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

    On Mon, Dec 31, 2007 at 09:43:15AM -0200, Otavio Salvador wrote:
    > dann frazier writes:
    >
    > >> imo, the best and more widly solution would be the 2. That shouldn't
    > >> be too hard and would allow us to reduce the memory footprint not only
    > >> on your user case but in general usage too.

    > >
    > > Might be vearing off topic for this bug, but here's a wrapper I worked
    > > up (not yet tested in the d-i environment).

    >
    > It looks nice.
    >
    > I think that code might be more clear if you change the cleanup step
    > to be a funtion and it will make simpler to spot what is being done in
    > each case.


    Yes, this does improve readability.

    > I see no point in using aggresive policy. It would unload the modules
    > detected by udev and since we provide a small set of modules it looks
    > useless to me. Do you see any possible usage?


    No - it was just something I was playing with (see my comment in the
    code warning people not to use it). Also, I only think it makes sense
    to include a policy setting if its an option - e.g. an environment
    variable. If we find only only one policy useful, the others should be
    dropped to reduce code size/complexity.

    Attached is a new version that incorporates your factoring suggestion,
    and does away with the policy options.

    --
    dann frazier



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

    dann frazier writes:

    >> I think that code might be more clear if you change the cleanup step
    >> to be a funtion and it will make simpler to spot what is being done in
    >> each case.

    >
    > Yes, this does improve readability.


    And it did, indeed. This lastest version is much easier to read. :-)
    Nice job.

    >> I see no point in using aggresive policy. It would unload the modules
    >> detected by udev and since we provide a small set of modules it looks
    >> useless to me. Do you see any possible usage?

    >
    > No - it was just something I was playing with (see my comment in the
    > code warning people not to use it). Also, I only think it makes sense
    > to include a policy setting if its an option - e.g. an environment
    > variable. If we find only only one policy useful, the others should be
    > dropped to reduce code size/complexity.


    Great.

    It looks like we just need to put it inside of d-i and see if it gives
    any regression, otherwise it looks like a nice improvement of what we
    have now.

    Have you done any test to see if it changes the memory footprint?

    --
    O T A V I O S A L V A D O R
    ---------------------------------------------
    E-mail: otavio@debian.org UIN: 5906116
    GNU/Linux User: 239058 GPG ID: 49A5F855
    Home Page: http://otavio.ossystems.com.br
    ---------------------------------------------
    "Microsoft sells you Windows ... Linux gives
    you the whole house."



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

+ Reply to Thread