From: James Smart <James.Smart@Emulex.Com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Patrick Mansfield <patmans@us.ibm.com>, linux-scsi@vger.kernel.org
Subject: Re: [RFC] printks in print_inquiry
Date: Fri, 19 May 2006 15:43:26 -0400 [thread overview]
Message-ID: <446E1FDE.1080404@emulex.com> (raw)
In-Reply-To: <20060519190848.GA2826@parisc-linux.org>
Matthew Wilcox wrote:
> On Thu, May 18, 2006 at 01:09:57PM -0700, Patrick Mansfield wrote:
>>> scsi: 2:0:1:0: Vendor: HP 18.2G Model: ATLAS10K3_18_SCA Rev: HP05 ANSI rev: 02
>> That is very nice ... as is replacing print_inquiry with one line of code.
>
> Thanks. However, I'm now wondering about the length of the line.
> Aren't people agitating to replace the channel with a string? which
> could be longer than the, oh, three bytes left after the end of the
> current string? Losing the scsi: isn't really a good idea. So how
> about:
>
> scsi: 2:0:1:0 Device: HP 18.2G ATLAS10K3_18_SCA HP05 ANSI 02
> scsi: 4:0:2:0 Device: HP DVD-ROM 305 1.01 ANSI 02
>
> If we really wanted to be smart, we could even do:
>
> scsi: 2:0:1:0 Direct-Access HP 18.2G ATLAS10K3_18_SCA HP05 ANSI 02
> scsi: 4:0:2:0 CD-ROM HP DVD-ROM 305 1.01 ANSI 02
I wouldn't bother with the device type, unless you are reporting it as the
byte0 contents (eg. PQ bits and dev type). I would like to see the PQ bits.
I also expect the class driver to typically bind to the device right after
this, so I'll get the sd or st lines which will further reflect device type.
> I'm still in two minds about even reporting the ANSI version. Is there
> ever a time when having that information would be useful to debug a
> problem *and* we don't have access to that (eg through sysfs)?
It makes a difference if debugging a scan issue. I would think it's useful
to see what Lun 0 has as it drives other scanning.
-- james s
next prev parent reply other threads:[~2006-05-19 19:43 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-11 15:00 [RFC] printks in print_inquiry Matthew Wilcox
2006-05-12 17:08 ` Patrick Mansfield
2006-05-13 5:00 ` Matthew Wilcox
2006-05-18 18:36 ` Matthew Wilcox
2006-05-18 20:09 ` Patrick Mansfield
2006-05-19 19:08 ` Matthew Wilcox
2006-05-19 19:43 ` James Smart [this message]
2006-05-20 14:19 ` Matthew Wilcox
2006-05-20 14:33 ` James Bottomley
2006-05-19 20:11 ` dev_printk output Matthew Wilcox
2006-05-19 20:28 ` Greg KH
2006-05-20 4:55 ` Matthew Wilcox
2006-05-20 13:46 ` James Bottomley
2006-05-20 21:21 ` Greg KH
2006-05-29 3:57 ` Matthew Wilcox
2006-05-29 16:30 ` James Bottomley
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=446E1FDE.1080404@emulex.com \
--to=james.smart@emulex.com \
--cc=linux-scsi@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=patmans@us.ibm.com \
/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.