public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Patrick Mochel <mochel@osdl.org>
Cc: Nick Bellinger <nickb@attheoffice.org>,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: driverfs bus_id, name (was: [PATCH] /proc/scsi/map)
Date: Tue, 25 Jun 2002 12:55:58 -0700	[thread overview]
Message-ID: <3D18CACE.608@pacbell.net> (raw)
In-Reply-To: Pine.LNX.4.33.0206251159040.8496-100000@geena.pdx.osdl.net

>>- It'd be more appropriate for PCI devices to copy pci_device.name into
>>   device.name and get the user-friendly names from the PCI device name
>>   database (when available), and only fallback to those nasty strings
>>   when the more user-friendly names aren't available.
> 
> 
> That is what happens with PCI devices. They're not appearing as meaningful 
> names probably because CONFIG_PCI_NAMES isn't set. Whether or not that 
> information belongs in the kernel is another debate. 

ERm ... it wasn't on the systems I looked at.  CONFIG_PCI_NAMES has
clearly been set, but the names were the user-unfriendly style.  And
yet I know the kernel has them accessible, since they're presented
by the USB layer and by /proc/pci.  But not in driverfs.

I now see some code (presumably yours) to set those two fields
to be identical, in pci_scan_device(), but the useful description
is instead set in pci_scan_slot().  Presumably this is a case of
various init paths in PCI not wholly agreeing with each other;
maybe pci_name_device() should set both name/description fields
instead of only the one.  (Though ... why have two copies? :)


>>- Likewise it'd be more appropriate for USB devices to take the
>>   descriptive strings from the devices, like "Philips USB Digital
>>   Speaker System", than "USB device 0471:0104".
> 
> 
> Those are in the devices themselves, right? There is nothing stopping the 
> USB people from doing that... ;)

Good, I was just sanity checking ... since the PCI names really
haven't worked to provide user-friendly names, and I couldn't tell
if that was intentional.  I can provide a patch for USB easily.


You didn't respond to the question about changing the identifier
from "name" to be the more appropriate "description" ... is that
because you're still thinking (it'd cost to change) or because
you like using the (IMO ambiguous) identifier "name" there?

- Dave



  reply	other threads:[~2002-06-25 19:53 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-22 17:24 [PATCH] /proc/scsi/map David Brownell
2002-06-22 17:48 ` Roman Zippel
2002-06-22 20:11   ` Douglas Gilbert
2002-06-22 20:57     ` Roman Zippel
2002-06-22 18:18 ` Nick Bellinger
2002-06-24  1:50   ` David Brownell
2002-06-25 16:46   ` Patrick Mochel
2002-06-25 16:33 ` Patrick Mochel
2002-06-25 17:47   ` driverfs bus_id, name (was: [PATCH] /proc/scsi/map) David Brownell
2002-06-25 19:06     ` Patrick Mochel
2002-06-25 19:55       ` David Brownell [this message]
2002-07-01 17:25         ` Patrick Mochel
2002-06-25 17:49   ` [PATCH] /proc/scsi/map David Brownell
2002-06-26 23:39     ` Nick Bellinger
2002-07-01 17:45       ` Patrick Mochel
2002-07-03  0:59     ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3D18CACE.608@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mochel@osdl.org \
    --cc=nickb@attheoffice.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox