On Friday 07 December 2007, dann frazier wrote: > 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. 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). 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. > 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. See my reply to Otavio's mail. > > - 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. Yes, so we really need some different implementation. I still feel that PCI slot is not something that is meaningful to a lot of end users, although of course it would be to sysadmins. Therefore I don't really like the idea of showing it by default together with the description. I'd prefer showing it on a separate "disambiguation" screen (see my reply to Joey's mail). > > - 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. Showing the MAC address would remove _all_ ambiguity and would not require loading any additional modules. > > - 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. It's based on this change (indentation reduced): - if [ "$vendorname" ] || [ "$devicename" ]; then - echo "$dev:$vendorname $devicename" >> /etc/network/devnames + if [ "$vendorname" ] || [ "$devicename" ] || [ "$slot" ]; then + echo "$dev:$slot$vendorname $devicename"> /etc/network/devnames Adding '|| [ "$slot" ]' means that slot could be added if both vendor and device are empty. That is probably unlikely, but if it would happen I wonder if it is desirable. I'd suggest to only write a line if at least vendor or device are available. > > 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. See my reply to Joey for an example of my proposal. > 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). Also, Geert's proposal to show all details on a single screen is totally unworkable if you _do_ have 20 or so NICs in a system. > 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. Well, if someone is willing to do the work to extend debconf... > * 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. And would probably hurt preseeding. Note that I'm still open to the idea of adding slot info. But only if the cost in memory usage is not too high when compared to the benefits and if the user interface remains understandable for non-technical users that don't need the additional info because the descriptions already provide sufficient identification. I'm all for a solution that helps people with multiple identical NICs identify the correct one, but I'd like to see a real solution rather than just a partial and somewhat marginal improvement.
Attachment:
signature.asc
Description: This is a digitally signed message part.