lsscsi is a utility that uses sysfs in linux 2.6 series kernels
to list information about SCSI devices and SCSI hosts. Both a
compact format (default) which is one line per device and a
"classic" format (like the output of 'cat /proc/scsi/scsi') are
supported.
Version 0.17 is available at
http://www.torque.net/scsi/lsscsi.html
More information can be found on that page including examples
and a Download section for tarballs and rpms.
This version will be required for lsscsi to work properly
when lk 2.6.16 is released.
ChangeLog:
Version 0.17 2006/2/6
- fix disappearance of block device names in lk 2.6.16-rc1
Doug Gilbert
Douglas Gilbert <[email protected]> writes:
> Version 0.17 is available at
> http://www.torque.net/scsi/lsscsi.html
> More information can be found on that page including examples
> and a Download section for tarballs and rpms.
> This version will be required for lsscsi to work properly
> when lk 2.6.16 is released.
>
> ChangeLog:
> Version 0.17 2006/2/6
> - fix disappearance of block device names in lk 2.6.16-rc1
Does this work around new incompatibilities in the kernel
or does this fix lsscsi bugs?
--
Matthias Andree
Matthias Andree wrote:
> Douglas Gilbert <[email protected]> writes:
>>This version will be required for lsscsi to work properly
>>when lk 2.6.16 is released.
>>
>>ChangeLog:
>>Version 0.17 2006/2/6
>> - fix disappearance of block device names in lk 2.6.16-rc1
>
> Does this work around new incompatibilities in the kernel
> or does this fix lsscsi bugs?
The former. In lk 2.6.16-rc1 the
/sys/class/scsi_device/<hcil>/device/block symlink
changed to ".../block:sd<x>" breaking lsscsi 0.16 (and
earlier) and sg_map26 (in sg3_utils).
Doug Gilbert
On Wed, 22 Feb 2006, Douglas Gilbert wrote:
> Matthias Andree wrote:
> > Does this work around new incompatibilities in the kernel
> > or does this fix lsscsi bugs?
>
> The former. In lk 2.6.16-rc1 the
> /sys/class/scsi_device/<hcil>/device/block symlink
> changed to ".../block:sd<x>" breaking lsscsi 0.16 (and
> earlier) and sg_map26 (in sg3_utils).
Heck, what was the reason for breaking userspace again?
Why would someone even consider using sysfs at all if it changes
incompatibly?
--
Matthias Andree
Matthias Andree wrote:
> On Wed, 22 Feb 2006, Douglas Gilbert wrote:
>>Matthias Andree wrote:
>>>Does this work around new incompatibilities in the kernel
>>>or does this fix lsscsi bugs?
>>
>>The former. In lk 2.6.16-rc1 the
>>/sys/class/scsi_device/<hcil>/device/block symlink
>>changed to ".../block:sd<x>" breaking lsscsi 0.16 (and
>>earlier) and sg_map26 (in sg3_utils).
>
> Heck, what was the reason for breaking userspace again?
Maybe the person responsible can answer. I'm only reacting
to a change that broke two of my utilities.
> Why would someone even consider using sysfs at all if it changes
> incompatibly?
Indeed.
Doug Gilbert
On Wed, Feb 22, 2006 at 11:27:16AM -0500, Douglas Gilbert wrote:
> Matthias Andree wrote:
> > On Wed, 22 Feb 2006, Douglas Gilbert wrote:
> >>Matthias Andree wrote:
> >>>Does this work around new incompatibilities in the kernel
> >>>or does this fix lsscsi bugs?
> >>
> >>The former. In lk 2.6.16-rc1 the
> >>/sys/class/scsi_device/<hcil>/device/block symlink
> >>changed to ".../block:sd<x>" breaking lsscsi 0.16 (and
> >>earlier) and sg_map26 (in sg3_utils).
> >
> > Heck, what was the reason for breaking userspace again?
>
> Maybe the person responsible can answer. I'm only reacting
> to a change that broke two of my utilities.
Probably better to cc the person responsible if you want an answer.
> > Why would someone even consider using sysfs at all if it changes
> > incompatibly?
>
> Indeed.
There seems to be no committment to making sysfs a stable part of the
kernel API. Which is really just another way of saying "we can't be
bothered to design it upfront, we'll just let it evolve into a mess
and then try to fix it afterwards".
On Wed, 22 Feb 2006, Matthew Wilcox wrote:
> On Wed, Feb 22, 2006 at 11:27:16AM -0500, Douglas Gilbert wrote:
> > Matthias Andree wrote:
> > > On Wed, 22 Feb 2006, Douglas Gilbert wrote:
> > >>Matthias Andree wrote:
> > >>>Does this work around new incompatibilities in the kernel
> > >>>or does this fix lsscsi bugs?
> > >>
> > >>The former. In lk 2.6.16-rc1 the
> > >>/sys/class/scsi_device/<hcil>/device/block symlink
> > >>changed to ".../block:sd<x>" breaking lsscsi 0.16 (and
> > >>earlier) and sg_map26 (in sg3_utils).
> > >
> > > Heck, what was the reason for breaking userspace again?
> >
> > Maybe the person responsible can answer. I'm only reacting
> > to a change that broke two of my utilities.
>
> Probably better to cc the person responsible if you want an answer.
>
> > > Why would someone even consider using sysfs at all if it changes
> > > incompatibly?
> >
> > Indeed.
>
> There seems to be no committment to making sysfs a stable part of the
> kernel API. Which is really just another way of saying "we can't be
> bothered to design it upfront, we'll just let it evolve into a mess
> and then try to fix it afterwards".
I sorta hate to say this, but I was sitting/working a few feet
from Pat Mochel about 4 years ago when he was beginning on sysfs,
and I told him to watch out, it could end up a mess just like
procfs... :(
--
~Randy
On Wed, Feb 22, 2006 at 09:34:26AM -0700, Matthew Wilcox wrote:
> On Wed, Feb 22, 2006 at 11:27:16AM -0500, Douglas Gilbert wrote:
> > Matthias Andree wrote:
> > > On Wed, 22 Feb 2006, Douglas Gilbert wrote:
> > >>Matthias Andree wrote:
> > >>>Does this work around new incompatibilities in the kernel
> > >>>or does this fix lsscsi bugs?
> > >>
> > >>The former. In lk 2.6.16-rc1 the
> > >>/sys/class/scsi_device/<hcil>/device/block symlink
> > >>changed to ".../block:sd<x>" breaking lsscsi 0.16 (and
> > >>earlier) and sg_map26 (in sg3_utils).
> > >
> > > Heck, what was the reason for breaking userspace again?
> >
> > Maybe the person responsible can answer. I'm only reacting
> > to a change that broke two of my utilities.
>
> Probably better to cc the person responsible if you want an answer.
It was changed as there would be more than one "block" symlink in a
device's directory if more than one block device was attached to a
single struct device. For example, ub and multi-lun devices (there were
other reports of this happening for scsi devices too at the time from
what I remember.)
So, in that case, your tool would have been broken anyway, so this fix
was required to make it correct :)
The fix was to make block devices work the same way as all other class
devices, which had this fix a while ago.
thanks,
greg k-h
Greg KH wrote:
>>/sys/class/scsi_device/<hcil>/device/block symlink
>>changed to ".../block:sd<x>" breaking lsscsi 0.16 (and
>>earlier) and sg_map26 (in sg3_utils).
> It was changed as there would be more than one "block" symlink in a
> device's directory if more than one block device was attached to a
> single struct device. For example, ub and multi-lun devices (there were
> other reports of this happening for scsi devices too at the time from
> what I remember.)
A "scsi_device" is a logical unit, hence the "l" at
the end of the "<hcil>" acronym in the above path.
So it wasn't broken. However there is some fuzziness
in this area, for example the term "scsi_device".
Doug Gilbert
On Wed, 22 Feb 2006, Greg KH wrote:
> It was changed as there would be more than one "block" symlink in a
> device's directory if more than one block device was attached to a
> single struct device. For example, ub and multi-lun devices (there were
> other reports of this happening for scsi devices too at the time from
> what I remember.)
OK, just post an announcement to l-k when sysfs has stabilized enough to
be worth bothering.
--
Matthias Andree
On Wed, Feb 22, 2006 at 07:00:15PM +0100, Matthias Andree wrote:
> On Wed, 22 Feb 2006, Greg KH wrote:
>
> > It was changed as there would be more than one "block" symlink in a
> > device's directory if more than one block device was attached to a
> > single struct device. For example, ub and multi-lun devices (there were
> > other reports of this happening for scsi devices too at the time from
> > what I remember.)
>
> OK, just post an announcement to l-k when sysfs has stabilized enough to
> be worth bothering.
Um, this was a "bugfix". The kernel was creating multiple symlinks with
the same name, in the same directory, pointing to different locations.
How do you expect us to fix that in a format that does not change the
name of the symlink?
People sure are grumpy this morning...
greg k-h
On Wed, Feb 22, 2006 at 12:59:34PM -0500, Douglas Gilbert wrote:
> Greg KH wrote:
> >>/sys/class/scsi_device/<hcil>/device/block symlink
> >>changed to ".../block:sd<x>" breaking lsscsi 0.16 (and
> >>earlier) and sg_map26 (in sg3_utils).
>
> > It was changed as there would be more than one "block" symlink in a
> > device's directory if more than one block device was attached to a
> > single struct device. For example, ub and multi-lun devices (there were
> > other reports of this happening for scsi devices too at the time from
> > what I remember.)
>
> A "scsi_device" is a logical unit, hence the "l" at
> the end of the "<hcil>" acronym in the above path.
> So it wasn't broken. However there is some fuzziness
> in this area, for example the term "scsi_device".
Yes, but the block layer was not creating the proper symlink name, and
it would create multiple symlinks with the same name, in the same
directory, pointing to different places. That had to be fixed, as it
was broken. The block layer itself, has no way to determine if it is
using a scsi device, or another type of device, nor should it care.
thanks,
greg k-h
On Wed, 22 Feb 2006, Greg KH wrote:
> On Wed, Feb 22, 2006 at 07:00:15PM +0100, Matthias Andree wrote:
> > OK, just post an announcement to l-k when sysfs has stabilized enough to
> > be worth bothering.
>
> Um, this was a "bugfix".
Granted.
> The kernel was creating multiple symlinks with
> the same name, in the same directory, pointing to different locations.
> How do you expect us to fix that in a format that does not change the
> name of the symlink?
>
> People sure are grumpy this morning...
If you say so. I'd call it pure pragmatism: if the sysfs interface
still changes every other week or so, it's just annoying to chase these
changes in applications, so it seems just practical to wait until all
the bug fixes that require interface changes are in and the rate of
incompatible changes is well below 2/year -- and all the interesting
stuff is there.
--
Matthias Andree