public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <jbottomley@parallels.com>
To: "hare@suse.de" <hare@suse.de>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"kay@vrfy.org" <kay@vrfy.org>,
	"jlinton@tributary.com" <jlinton@tributary.com>,
	"dgilbert@interlog.com" <dgilbert@interlog.com>,
	"kai.makisara@kolumbus.fi" <kai.makisara@kolumbus.fi>
Subject: Re: [PATCH][RFC] Add EVPD page 0x83 entries to sysfs
Date: Wed, 12 Feb 2014 15:41:45 +0000	[thread overview]
Message-ID: <1392219704.2172.34.camel@dabdike> (raw)
In-Reply-To: <1391691878-61265-1-git-send-email-hare@suse.de>

On Thu, 2014-02-06 at 14:04 +0100, Hannes Reinecke wrote:
> EVPD page 0x83 is used to uniquely identify the device.
> So instead of having each and every program issue a separate
> SG_IO call to retrieve this information it does make far more
> sense to display it in sysfs.

Can someone please tell me what actual benefits we get from retrieving
an parsing this in the kernel instead of in userspace.  Just adding more
heuristics made your code grow by 150% since Thursday.  I'm really
worried about incomplete heuristics in the kernel because the process
for updating them is much more involved than simply doing an update to a
user package.

Please define what you're trying to achieve first, because if it's just
the best persistent name for the device it might be better to reverse
all of this and have a user writeable field in SCSI that udev populates
after it does all the heuristic stuff.  Is it a range (like name +
transport ID + other stuff) in which case we might get additional plug
ins to do that.

James


      parent reply	other threads:[~2014-02-12 15:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-06 13:04 [PATCH][RFC] Add EVPD page 0x83 entries to sysfs Hannes Reinecke
2014-02-06 13:12 ` Hannes Reinecke
2014-02-06 19:14 ` Douglas Gilbert
2014-02-07 15:15   ` Hannes Reinecke
2014-02-12 15:41 ` James Bottomley [this message]

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=1392219704.2172.34.camel@dabdike \
    --to=jbottomley@parallels.com \
    --cc=dgilbert@interlog.com \
    --cc=hare@suse.de \
    --cc=jlinton@tributary.com \
    --cc=kai.makisara@kolumbus.fi \
    --cc=kay@vrfy.org \
    --cc=linux-scsi@vger.kernel.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