From: Matthew Wilcox <matthew@wil.cx>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Bodo Eggert <7eggert@gmx.de>,
torvalds@osdl.org, linux-kernel@vger.kernel.org,
linux-scsi@vger.kernel.org
Subject: Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi
Date: Sun, 26 Mar 2006 13:08:26 -0700 [thread overview]
Message-ID: <20060326200826.GB3486@parisc-linux.org> (raw)
In-Reply-To: <1143402698.3055.28.camel@laptopd505.fenrus.org>
On Sun, Mar 26, 2006 at 09:51:38PM +0200, Arjan van de Ven wrote:
> On Sun, 2006-03-26 at 21:28 +0200, Bodo Eggert wrote:
> > Having a SCSI ID is a generic SCSI property, therefore reading it should
> > not be restricted to sg. The SCSI_IOCTL_GET_IDLUN from scsi is limited
> > below the kernel data types, so it isn't an adequate replacement.
> >
> > This patch moves SG_GET_SCSI_ID from sg to scsi while renaming it to
> > SCSI_IOCTL_GET_PCI. Additionally, I renamed struct sg_scsi_id to struct
> > scsi_ioctl_id, since it is no longer restricted to sg. The corresponding
> > typedef will be gone.
>
> To be honest, I think this is the wrong direction; this ioctl seems to
> be a bad idea (it exposes the SPI parameters... while SPI is only one of
> many nowadays). Expanding the use of such a thing... please no.
What's SPI specific?
+struct scsi_ioctl_id { /* used by SCSI_IOCTL_GET_ID ioctl() */
+ int host_no; /* as in "scsi<n>" where 'n' is one of 0, 1, 2
etc */
+ int channel;
+ int scsi_id; /* scsi id of target device */
+ int lun;
+ int scsi_type; /* TYPE_... defined in scsi/scsi.h */
+ short h_cmd_per_lun;/* host (adapter) maximum commands per lun */
+ short d_queue_depth;/* device (or adapter) maximum queue length */
+ int unused[2]; /* unused part should be zero */
+}; /* 32 bytes long on i386 */
Everything has to support HCIL, even if it's through some kind of
mapping. Yes, I know it might not make much *sense* for some
transports, but we do need to support it. Type isn't SPI-specific.
cmd_per_lun isn't SPI-specific either, and neither is d_queue_depth,
although neither may make too much sense for some adapters or targets.
next prev parent reply other threads:[~2006-03-26 20:08 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-26 19:28 [PATCH] Move SG_GET_SCSI_ID from sg to scsi Bodo Eggert
2006-03-26 19:51 ` Arjan van de Ven
2006-03-26 20:08 ` Matthew Wilcox [this message]
2006-03-26 20:41 ` Arjan van de Ven
2006-03-26 20:05 ` Matthew Wilcox
2006-03-27 10:11 ` Bodo Eggert
2006-03-27 15:20 ` Matthew Wilcox
2006-03-27 15:40 ` James Bottomley
2006-03-26 22:30 ` Linus Torvalds
2006-03-26 23:19 ` Jan Engelhardt
2006-03-27 0:06 ` Linus Torvalds
2006-03-27 11:42 ` Bodo Eggert
2006-03-28 9:43 ` Matthias Andree
2006-03-27 15:03 ` Douglas Gilbert
2006-03-27 17:15 ` Linus Torvalds
2006-03-27 17:25 ` Matthew Wilcox
2006-03-27 17:43 ` Linus Torvalds
2006-03-27 19:54 ` Alan Cox
2006-03-27 21:29 ` Douglas Gilbert
2006-03-28 7:37 ` Stefan Richter
2006-03-28 14:17 ` Jan Engelhardt
2006-03-26 23:09 ` Stefan Richter
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=20060326200826.GB3486@parisc-linux.org \
--to=matthew@wil.cx \
--cc=7eggert@gmx.de \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=torvalds@osdl.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