Looking around sysfs in an attempt to pull out SCSI card firmware
versions I found 5 different filenames used to store the information.
Only one, fw_version, was used more than once. The patch below changes
the other drivers to use this filename too.
I suspect the same applies to other subsystem drivers as well. I'll look
at them assuming this patch is well received.
Signed-Off-By: Jonathan McDowell <[email protected]>
-----
diff --git a/drivers/message/fusion/mptscsih.c b/drivers/message/fusion/mptscsih.c
index 626bb3c..ae80d04 100644
--- a/drivers/message/fusion/mptscsih.c
+++ b/drivers/message/fusion/mptscsih.c
@@ -3307,7 +3307,7 @@ mptscsih_version_fw_show(struct class_device *cdev, char *buf)
(ioc->facts.FWVersion.Word & 0x0000FF00) >> 8,
ioc->facts.FWVersion.Word & 0x000000FF);
}
-static CLASS_DEVICE_ATTR(version_fw, S_IRUGO, mptscsih_version_fw_show, NULL);
+static CLASS_DEVICE_ATTR(fw_version, S_IRUGO, mptscsih_version_fw_show, NULL);
static ssize_t
mptscsih_version_bios_show(struct class_device *cdev, char *buf)
diff --git a/drivers/scsi/arcmsr/arcmsr_attr.c b/drivers/scsi/arcmsr/arcmsr_attr.c
index 7d7b0a5..646f24c 100644
--- a/drivers/scsi/arcmsr/arcmsr_attr.c
+++ b/drivers/scsi/arcmsr/arcmsr_attr.c
@@ -352,7 +352,7 @@ static CLASS_DEVICE_ATTR(host_driver_posted_cmd, S_IRUGO, arcmsr_attr_host_drive
static CLASS_DEVICE_ATTR(host_driver_reset, S_IRUGO, arcmsr_attr_host_driver_reset, NULL);
static CLASS_DEVICE_ATTR(host_driver_abort, S_IRUGO, arcmsr_attr_host_driver_abort, NULL);
static CLASS_DEVICE_ATTR(host_fw_model, S_IRUGO, arcmsr_attr_host_fw_model, NULL);
-static CLASS_DEVICE_ATTR(host_fw_version, S_IRUGO, arcmsr_attr_host_fw_version, NULL);
+static CLASS_DEVICE_ATTR(fw_version, S_IRUGO, arcmsr_attr_host_fw_version, NULL);
static CLASS_DEVICE_ATTR(host_fw_request_len, S_IRUGO, arcmsr_attr_host_fw_request_len, NULL);
static CLASS_DEVICE_ATTR(host_fw_numbers_queue, S_IRUGO, arcmsr_attr_host_fw_numbers_queue, NULL);
static CLASS_DEVICE_ATTR(host_fw_sdram_size, S_IRUGO, arcmsr_attr_host_fw_sdram_size, NULL);
diff --git a/drivers/scsi/hptiop.c b/drivers/scsi/hptiop.c
index 0844331..ed130ec 100644
--- a/drivers/scsi/hptiop.c
+++ b/drivers/scsi/hptiop.c
@@ -634,7 +634,7 @@ static struct class_device_attribute hptiop_attr_version = {
static struct class_device_attribute hptiop_attr_fw_version = {
.attr = {
- .name = "firmware-version",
+ .name = "fw_version",
.mode = S_IRUGO,
},
.show = hptiop_show_fw_version,
diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
index 80a1121..32b1d2f 100644
--- a/drivers/scsi/lpfc/lpfc_attr.c
+++ b/drivers/scsi/lpfc/lpfc_attr.c
@@ -888,7 +888,7 @@ static CLASS_DEVICE_ATTR(modeldesc, S_IRUGO, lpfc_modeldesc_show, NULL);
static CLASS_DEVICE_ATTR(modelname, S_IRUGO, lpfc_modelname_show, NULL);
static CLASS_DEVICE_ATTR(programtype, S_IRUGO, lpfc_programtype_show, NULL);
static CLASS_DEVICE_ATTR(portnum, S_IRUGO, lpfc_vportnum_show, NULL);
-static CLASS_DEVICE_ATTR(fwrev, S_IRUGO, lpfc_fwrev_show, NULL);
+static CLASS_DEVICE_ATTR(fw_version, S_IRUGO, lpfc_fwrev_show, NULL);
static CLASS_DEVICE_ATTR(hdw, S_IRUGO, lpfc_hdw_show, NULL);
static CLASS_DEVICE_ATTR(state, S_IRUGO, lpfc_state_show, NULL);
static CLASS_DEVICE_ATTR(option_rom_version, S_IRUGO,
-----
J.
--
Web [ The World's most affectionate creature is a muddy dog. ]
site: http:// [ ] Made by
http://www.earth.li/~noodles/ [ ] HuggieTag 0.0.23
The hearburn I have with these patches is that you are changing driver-specific
attributes, not common ones as enforced/requested by a subsystem. As such, you
are breaking a management interface for existing tools/scripts.
There's been a long-standing request to create common device attributes, such as
fw_version, but I don't think they ever made it into the kernel. Not only would
the names be consistent, but the location would be consistent as well.
I'd rather you took on that work, than proceed with these patches.
-- james s
Jonathan McDowell wrote:
> Looking around sysfs in an attempt to pull out SCSI card firmware
> versions I found 5 different filenames used to store the information.
> Only one, fw_version, was used more than once. The patch below changes
> the other drivers to use this filename too.
>
> I suspect the same applies to other subsystem drivers as well. I'll look
> at them assuming this patch is well received.
>
> Signed-Off-By: Jonathan McDowell <[email protected]>
>
> -----
> diff --git a/drivers/message/fusion/mptscsih.c b/drivers/message/fusion/mptscsih.c
> index 626bb3c..ae80d04 100644
> --- a/drivers/message/fusion/mptscsih.c
> +++ b/drivers/message/fusion/mptscsih.c
> @@ -3307,7 +3307,7 @@ mptscsih_version_fw_show(struct class_device *cdev, char *buf)
> (ioc->facts.FWVersion.Word & 0x0000FF00) >> 8,
> ioc->facts.FWVersion.Word & 0x000000FF);
> }
> -static CLASS_DEVICE_ATTR(version_fw, S_IRUGO, mptscsih_version_fw_show, NULL);
> +static CLASS_DEVICE_ATTR(fw_version, S_IRUGO, mptscsih_version_fw_show, NULL);
>
> static ssize_t
> mptscsih_version_bios_show(struct class_device *cdev, char *buf)
> diff --git a/drivers/scsi/arcmsr/arcmsr_attr.c b/drivers/scsi/arcmsr/arcmsr_attr.c
> index 7d7b0a5..646f24c 100644
> --- a/drivers/scsi/arcmsr/arcmsr_attr.c
> +++ b/drivers/scsi/arcmsr/arcmsr_attr.c
> @@ -352,7 +352,7 @@ static CLASS_DEVICE_ATTR(host_driver_posted_cmd, S_IRUGO, arcmsr_attr_host_drive
> static CLASS_DEVICE_ATTR(host_driver_reset, S_IRUGO, arcmsr_attr_host_driver_reset, NULL);
> static CLASS_DEVICE_ATTR(host_driver_abort, S_IRUGO, arcmsr_attr_host_driver_abort, NULL);
> static CLASS_DEVICE_ATTR(host_fw_model, S_IRUGO, arcmsr_attr_host_fw_model, NULL);
> -static CLASS_DEVICE_ATTR(host_fw_version, S_IRUGO, arcmsr_attr_host_fw_version, NULL);
> +static CLASS_DEVICE_ATTR(fw_version, S_IRUGO, arcmsr_attr_host_fw_version, NULL);
> static CLASS_DEVICE_ATTR(host_fw_request_len, S_IRUGO, arcmsr_attr_host_fw_request_len, NULL);
> static CLASS_DEVICE_ATTR(host_fw_numbers_queue, S_IRUGO, arcmsr_attr_host_fw_numbers_queue, NULL);
> static CLASS_DEVICE_ATTR(host_fw_sdram_size, S_IRUGO, arcmsr_attr_host_fw_sdram_size, NULL);
> diff --git a/drivers/scsi/hptiop.c b/drivers/scsi/hptiop.c
> index 0844331..ed130ec 100644
> --- a/drivers/scsi/hptiop.c
> +++ b/drivers/scsi/hptiop.c
> @@ -634,7 +634,7 @@ static struct class_device_attribute hptiop_attr_version = {
>
> static struct class_device_attribute hptiop_attr_fw_version = {
> .attr = {
> - .name = "firmware-version",
> + .name = "fw_version",
> .mode = S_IRUGO,
> },
> .show = hptiop_show_fw_version,
> diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
> index 80a1121..32b1d2f 100644
> --- a/drivers/scsi/lpfc/lpfc_attr.c
> +++ b/drivers/scsi/lpfc/lpfc_attr.c
> @@ -888,7 +888,7 @@ static CLASS_DEVICE_ATTR(modeldesc, S_IRUGO, lpfc_modeldesc_show, NULL);
> static CLASS_DEVICE_ATTR(modelname, S_IRUGO, lpfc_modelname_show, NULL);
> static CLASS_DEVICE_ATTR(programtype, S_IRUGO, lpfc_programtype_show, NULL);
> static CLASS_DEVICE_ATTR(portnum, S_IRUGO, lpfc_vportnum_show, NULL);
> -static CLASS_DEVICE_ATTR(fwrev, S_IRUGO, lpfc_fwrev_show, NULL);
> +static CLASS_DEVICE_ATTR(fw_version, S_IRUGO, lpfc_fwrev_show, NULL);
> static CLASS_DEVICE_ATTR(hdw, S_IRUGO, lpfc_hdw_show, NULL);
> static CLASS_DEVICE_ATTR(state, S_IRUGO, lpfc_state_show, NULL);
> static CLASS_DEVICE_ATTR(option_rom_version, S_IRUGO,
> -----
>
> J.
>
On Tue, Nov 20, 2007 at 11:35:26AM -0500, James Smart wrote:
> The hearburn I have with these patches is that you are changing
> driver-specific attributes, not common ones as enforced/requested by a
> subsystem. As such, you are breaking a management interface for
> existing tools/scripts.
Yes, that's true. Though at present we have the heartburn that anyone
wanting to write a script to pull out firmware revisions has to know
exactly where every driver stores this information.
> There's been a long-standing request to create common device
> attributes, such as fw_version, but I don't think they ever made it
> into the kernel. Not only would the names be consistent, but the
> location would be consistent as well.
>
> I'd rather you took on that work, than proceed with these patches.
Do you have a pointer to previous discussion about this? A central
device attribute does make more sense. It'd be nice to have uniform
access to details like the driver version as well.
> Jonathan McDowell wrote:
> >Looking around sysfs in an attempt to pull out SCSI card firmware
> >versions I found 5 different filenames used to store the information.
> >Only one, fw_version, was used more than once. The patch below changes
> >the other drivers to use this filename too.
> >
> >I suspect the same applies to other subsystem drivers as well. I'll look
> >at them assuming this patch is well received.
J.
--
You have a tendency to feel you are superior to most computers.
This .sig brought to you by the letter U and the number 25
Product of the Republic of HuggieTag
Jonathan McDowell sez:
> On Tue, Nov 20, 2007 at 11:35:26AM -0500, James Smart wrote:
> > The hearburn I have with these patches is that you are changing
> > driver-specific attributes, not common ones as
> > enforced/requested by a
> > subsystem. As such, you are breaking a management interface for
> > existing tools/scripts.
> Yes, that's true. Though at present we have the heartburn that anyone
> wanting to write a script to pull out firmware revisions has to know
> exactly where every driver stores this information.
The aacraid cards, which uses hba_monitor_version, hba_kernel_version
and hba_bios_version for each piece does not fit into the single
'firmware revision' common ideal and were noticeably missing from this
patch set.
Fortunately (?), Adaptec has not bought into using sysfs for their
management applications to pull these pieces and continues to pick them
up directly by issuing ioctl pass-through calls to the card's firmware,
so we have some leeway to change them to mold to a developing standard.
The fact that sysfs is a developing standard will confirm the management
application folks reasoning for shying away from sysfs ;-/
Sincerely -- Mark Salyzyn
On Tue, Nov 20, 2007 at 12:49:49PM -0500, Salyzyn, Mark wrote:
> Jonathan McDowell sez:
> > On Tue, Nov 20, 2007 at 11:35:26AM -0500, James Smart wrote:
> > > The hearburn I have with these patches is that you are changing
> > > driver-specific attributes, not common ones as enforced/requested
> > > by a subsystem. As such, you are breaking a management interface
> > > for existing tools/scripts.
> > Yes, that's true. Though at present we have the heartburn that
> > anyone wanting to write a script to pull out firmware revisions has
> > to know exactly where every driver stores this information.
>
> The aacraid cards, which uses hba_monitor_version, hba_kernel_version
> and hba_bios_version for each piece does not fit into the single
> 'firmware revision' common ideal and were noticeably missing from this
> patch set.
I mainly looked for mentions of "firmware" to try and work out which
drivers were exporting this information in a single file. While I've
used the aacraid cards in the past I think I agree with you that no 1 of
those 3 pieces of information represents the firmware. Perhaps it could
export a triplet though?
> Fortunately (?), Adaptec has not bought into using sysfs for their
> management applications to pull these pieces and continues to pick
> them up directly by issuing ioctl pass-through calls to the card's
> firmware, so we have some leeway to change them to mold to a
> developing standard. The fact that sysfs is a developing standard
> will confirm the management application folks reasoning for shying
> away from sysfs ;-/
Management stuff always seems to be tied to a single card. It's one of
the things that puts me off hardware RAID. It would really rock if we
could get as much as possible exported in the same fashion across cards,
rather than having to cope with each individually (though I accept that
accessing all details/features will probably always require some custom
card knowledge).
Do the management folks actually have some ideas about what sort of
interface they'd like in sysfs?
J.
--
If I save time, when do I get it back?
Jonathan McDowell [mailto:[email protected]] sez:
> On Tue, Nov 20, 2007 at 12:49:49PM -0500, Salyzyn, Mark wrote:
> > The aacraid cards, which uses hba_monitor_version,
> > hba_kernel_version and hba_bios_version for each piece
> > does not fit into the single 'firmware revision' common ideal
> While I've used the aacraid cards in the past I think I agree
> with you that no 1 of those 3 pieces of information represents
> the firmware. Perhaps it could export a triplet though?
A single can be used in 99% of all cases, OEM or users can muck
it up. I would 'vote' for hba_kernel_version == fw_version.
Maybe add a companion standard for hba_bios_version == bios_version
and hba_monitor_version == exec_version (executive_version) if other
cards can supply such info ...
> Management stuff always seems to be tied to a single card. It's one of
> the things that puts me off hardware RAID.
There are 113 cards this driver works for in concert. Maybe my tail
feathers are showing ;->
> Do the management folks actually have some ideas about what sort of
> interface they'd like in sysfs?
Simple answer:
No
Detailed answer (I digress):
They love ioctls as a commonality across all operating
systems and a pass-through to proprietary firmware
portals: binary, bidirectional, atomic and freely
formatted migrating structures that do not herd the
cats into just one specification. These are all
eventually presented as documented stable objects
exported by a sizeable C++ StorLib(tm) library that
provides the consistent interface that the OEMs and
Adaptec use to the higher level install, event, GUI
and CLI applications. Driver is only involved as a
transport.
Sincerely -- Mark Salyzyn
> > Management stuff always seems to be tied to a single card. It's one of
> > the things that puts me off hardware RAID.
>
> There are 113 cards this driver works for in concert. Maybe my tail
> feathers are showing ;->
You might want to mention the card firmware in question run on 3 or 4
entirely different processors too
> > Do the management folks actually have some ideas about what sort of
> > interface they'd like in sysfs?
>
> Simple answer:
> No
>
> Detailed answer (I digress):
Linuxy answer:
Something like netlink
Alan