Bug#454493: Display PCI slot for nics, if available
On Thu, Dec 06, 2007 at 01:34:25AM +0100, Frans Pop wrote:
> On Wednesday 05 December 2007, dann frazier wrote:
> > This patch to hw-detect adds slot information, if available, to the
> > network device name. Its not uncommon for HP (or our customers) to
> > have systems with many network devices, and knowing the physical slot
> > number of an adapter makes configuration that much easier.
>
> I have several reservations against this patch:
> - to have it work for all installation methods you'd need to to include
> this acpi module (and others?) in initrds, which is something we don't
> do lightly [1]
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.
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.
> - the "slot" indication is not translatable in the current patch
I didn't think to make this translatable, but yes, it should be.
> - the descriptions are already quite long and this will truncate some of
> them even more than they already are
Yeah, I expected someone would point this out. There are possible
hacks like filtering out redundant words/phrases like "Ethernet
Controller", but I think what we really need is to get out of the
single-line description, more on this below.
> - I'm not sure that as a user it would be clear to me what exactly a Slot
> is in this context
I could change this to "PCI Slot" or "PCI Card Slot", and would even
prefer it, but that will of course take more space.
> - looking at your screenshot it does not seem to add all that much
> identification as there are still several NICs with identical slots
The snapshot was taken from a machine w/ dual-port cards installed, so
it is correct for both nics to claim the same slot. This case does
leave some ambiguity, but much less ambiguity than before.
> - it seems only a partial solution as not all NICs will be get a slot
> identifier
Again, it decreases ambiguity. In my screenshot, you can see that two
nics aren't in slots because they are built into the system board. You
don't know which one is which, but in a system with 20 nics, it
certainly saves you some time finding the right one. (And 20 NICs
really isn't a contrived example, but is of course a small minority of
Debian users).
> - I'm not sure that it makes sense to print slot if it's the only
> identification
Can you restate this one - I didn't really follow it.
> We've had other requests to provide additional identification of NICs (see
> #450605 and merged BRs) and so far we (or at least I) have been thinking of
> some way to display the MAC address, possibly by allowing to switch between
> display of the current descriptions and MAC address.
That would help some users, but I'd like to see us find a more general
way to display all the available information that a user might use for
identification. And I expect a separate display, or "view" for each
may prove not to scale.
I do like the genearl principle of Geert's proposal:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=450605#31
With the exception that I don't like splitting the option list from
the selection widget (and as Bastian points out, its not possible
anyway).
Some brainstorming:
* Modify cdebconf to permit per-option descriptions, and use those
descriptions to provide details about each nic. Frontends could
use this to implement a "more info" button, or just include the
description text in-line.
* Modify cdebconf to support multi-line choice fields. Make each
interface choice be a multi-lined option that includes things like
vendor, model, mac, slot.
* Change the flow from "select iface" -> "configure iface" to:
"select iface"
v
"display info about iface & confirm"
v
"configure iface"
This is probably the only one possible w/ today's cdebconf, but its
pretty non-intuitive.
--
dann frazier
Reply to: