From: Hannes Reinecke <hare@suse.de>
To: Christoph Hellwig <hch@infradead.org>
Cc: James Bottomley <jbottomley@parallels.com>,
linux-scsi@vger.kernel.org, Jeremy Linton <jlinton@tributary.com>,
Kay Sievers <kay@vrfy.org>, Doug Gilbert <dgilbert@interlog.com>,
Kai Makisara <kai.makisara@kolumbus.fi>
Subject: Re: [PATCH 2/2] Add EVPD page 0x83 entries to sysfs
Date: Wed, 12 Feb 2014 09:26:59 +0100 [thread overview]
Message-ID: <52FB3053.6060108@suse.de> (raw)
In-Reply-To: <20140212080256.GA18203@infradead.org>
On 02/12/2014 09:02 AM, Christoph Hellwig wrote:
> On Tue, Feb 11, 2014 at 03:34:54PM +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.
>> The page is displayed in its entirety with the attribute
>> 'vpd_pg83', and the individual designators are stored in
>> ident_<association>_<designator> attributes.
>> Duplicate designators are added as individual lines to
>> the corresponding attribute.
>
> Looks correct to me, suggestions for a few possible cleanups below.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
>
>> +#define SCSI_VPD_ASSOC_lun 0x0
>> +#define SCSI_VPD_ASSOC_port 0x1
>> +#define SCSI_VPD_ASSOC_target 0x2
>> +
>> +#define SCSI_VPD_DESIG_vendor 0x0
>> +#define SCSI_VPD_DESIG_t10 0x1
>> +#define SCSI_VPD_DESIG_eui 0x2
>> +#define SCSI_VPD_DESIG_naa 0x3
>> +#define SCSI_VPD_DESIG_relport 0x4
>> +#define SCSI_VPD_DESIG_tpgrp 0x5
>> +#define SCSI_VPD_DESIG_lugrp 0x6
>> +#define SCSI_VPD_DESIG_md5 0x7
>> +#define SCSI_VPD_DESIG_scsi_name 0x8
>> +#define SCSI_VPD_DESIG_proto 0x9
>
> Shouldn't these constants be in a header?
>
Radio Yerewan answers: In principle, yes.
But then the definitions a closely tied to the following macro
(hence the lowercase in the last string), so it's not _that_
useful for a general definition.
If we were to move the constants into a header I'd have
to re-do all the macros (up to and including DEVICE_ATTR)
building up the sysfs attributes. Which currently doesn't
give any benefits whatsoever.
But if someone insists ...
>> + switch (d[0] >> 4) {
>> + case SCSI_PROTOCOL_FCP:
>> + proto = "fcp";
>> + break;
>> + case SCSI_PROTOCOL_SPI:
>> + proto = "spi";
>> + break;
>
> Splitting the protocol mapping into a separate helper woulkd be good.
> In fact this could easily be an array lookup as well.
>
Ok.
>> +#define sdev_evpd_test_and_show_attr(sdev, attr, assoc, desig) \
>> + if (attr == &dev_attr_ident_##assoc##_##desig.attr) { \
>> + if (scsi_test_vpd_ident(sdev, SCSI_VPD_ASSOC_##assoc, \
>> + SCSI_VPD_DESIG_##desig)) \
>> + return S_IRUGO; \
>> + else \
>> + return 0; \
>
> No need for the else here.
>
Bzzt. The "else" branch is required, the "if" branch can be skipped.
(hch was wrong! Quick, mark the day!)
>> + if (attr == &dev_attr_vpd_pg83.attr) {
>> + if (sdev->vpd_ident)
>> + return S_IRUGO;
>> + else
>> + return 0;
>> + }
>
> Same here.
>
:-)
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2014-02-12 8:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-11 14:34 [PATCHv5 0/2] Display EVPD pages in sysfs Hannes Reinecke
2014-02-11 14:34 ` [PATCH 1/2] scsi_sysfs: Implement 'is_visible' callback Hannes Reinecke
2014-02-12 7:57 ` Christoph Hellwig
2014-02-11 14:34 ` [PATCH 2/2] Add EVPD page 0x83 entries to sysfs Hannes Reinecke
2014-02-12 8:02 ` Christoph Hellwig
2014-02-12 8:26 ` Hannes Reinecke [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=52FB3053.6060108@suse.de \
--to=hare@suse.de \
--cc=dgilbert@interlog.com \
--cc=hch@infradead.org \
--cc=jbottomley@parallels.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.