From: Douglas Gilbert <dougg@torque.net>
To: Patrick Mansfield <patmans@us.ibm.com>
Cc: James.Bottomley@steeleye.com, linux-scsi@vger.kernel.org
Subject: Re: [PATCH] scsi-misc-2.5 remove scsi_scan.c EVPD code
Date: Tue, 06 May 2003 15:58:02 +1000 [thread overview]
Message-ID: <3EB74EEA.7030300@torque.net> (raw)
In-Reply-To: <20030505211158.A14613@beaverton.ibm.com>
Patrick Mansfield wrote:
> On Tue, May 06, 2003 at 11:39:24AM +1000, Douglas Gilbert wrote:
>
>>Patrick Mansfield wrote:
<snip/>
>>Another approach could be to have a device node for
>>the scsi mid level (e.g. /dev/scsi) with an ioctl
>>that takes a device's toplogical address and some
>>parameters (e.g. VPD_83) and yields the response
>>of that INQUIRY (or yields an scsi status and a
>>sense buffer).
>
>
> Can something like that be done for a /dev/sg today? It would be very
> useful, not only for VPD/id like commands, but also for user level
> scanning.
It can be. There are a few details to be worked out.
In lk 2.4 for example the sg driver is not initialized
if there are no SCSI devices. That would cause a chicken
and egg type situation if sg was used to do user level
scanning to find the first scsi device. What major/minor
should /dev/sg have? (It could be a misc device and get
a minor reserved).
> That is open some /dev/sg via an ioctl (or ?) attach it to a nexus. If
> there is an existing scsi_device with a matching nexus, it can attach to
> it, else create an sdev via scsi_alloc_sdev, attach to it and go.
>
> Then we can send whatever commands we want via current sg interfaces.
Sounds good. Only allow /dev/sg to have one nexus at
a time "open" (per file descriptor)? Could it
delete an existing nexus?
Doug Gilbert
next prev parent reply other threads:[~2003-05-06 5:42 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-25 0:47 [PATCH] scsi-misc-2.5 remove scsi_scan.c EVPD code Andries.Brouwer
2003-05-05 7:58 ` Douglas Gilbert
2003-05-05 14:17 ` James Bottomley
2003-05-05 15:52 ` Mike Anderson
2003-05-05 16:14 ` James Bottomley
2003-05-05 16:26 ` Patrick Mansfield
2003-05-05 16:57 ` Mike Anderson
2003-05-05 17:01 ` James Bottomley
2003-05-05 16:38 ` Patrick Mansfield
2003-05-05 16:59 ` James Bottomley
2003-05-05 17:46 ` Mike Anderson
2003-05-05 22:51 ` Patrick Mansfield
2003-05-06 1:39 ` Douglas Gilbert
2003-05-06 4:11 ` Patrick Mansfield
2003-05-06 5:58 ` Douglas Gilbert [this message]
2003-05-06 21:11 ` Patrick Mansfield
-- strict thread matches above, loose matches on Subject: below --
2003-04-25 0:22 Patrick Mansfield
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=3EB74EEA.7030300@torque.net \
--to=dougg@torque.net \
--cc=James.Bottomley@steeleye.com \
--cc=linux-scsi@vger.kernel.org \
--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.