From: Erik Andersen <andersen@codepoet.org>
To: Jens Axboe <axboe@suse.de>
Cc: linux-kernel@vger.kernel.org, Jeff Garzik <jgarzik@pobox.com>
Subject: Re: [PATCH] bsg, block layer sg
Date: Mon, 6 Mar 2006 11:30:46 -0700 [thread overview]
Message-ID: <20060306183046.GA15179@codepoet.org> (raw)
In-Reply-To: <20060302111945.GG4329@suse.de>
On Thu Mar 02, 2006 at 12:19:46PM +0100, Jens Axboe wrote:
> Hi,
>
> After all that SG_IO and cdrecord talk, I decided to brush off the bsg
> driver I wrote some time ago. Basically this is a full (aims to be at
> least, probably still some minor bits missing) SG v3 interface. It
> supports both SG_IO (which we just pass through for now), as well as
> read/write and readv/writev of sg_io_hdr structures.
After this is merged I suppose I could then, i.e. run an SG_IO
ioctl doing i.e. INQUIRY_CMD with some random block device, such
as an /dev/nbd0, or /dev/loop0, or some such. Which in general
does not seem to make any sense at all unless the block device
has some physical device level support for SCSI/ATAPI/MMC. So
while it addresses the needs of cdrecord and friends for CD
burning, does it make sense to implement this as a general
capability for all block devices? I'm not objecting or arguing,
I'm simply puzzled why a generic SG_IO layer for _all_ block
devices (whether SCSI/ATAPI/MMC capable or not) is useful?
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
next prev parent reply other threads:[~2006-03-06 18:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-02 11:19 [PATCH] bsg, block layer sg Jens Axboe
2006-03-02 11:22 ` Jeff Garzik
2006-03-05 2:08 ` Andrew Morton
2006-03-06 8:57 ` Jens Axboe
2006-03-06 9:13 ` Andrew Morton
2006-03-06 9:19 ` Jens Axboe
2006-03-06 9:25 ` Jens Axboe
2006-03-06 18:30 ` Erik Andersen [this message]
2006-03-06 18:57 ` Jens Axboe
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=20060306183046.GA15179@codepoet.org \
--to=andersen@codepoet.org \
--cc=axboe@suse.de \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.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