Re: [PATCH 4/6] virtio block driver

[Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>]

On Thu, 2007-09-20 at 14:27 +0200, Jens Axboe wrote:
> On Thu, Sep 20 2007, Rusty Russell wrote:
> > The block driver uses scatter-gather lists with sg[0] being the
> > request information (struct virtio_blk_outhdr) with the type, sector
> > and inbuf id.  The next N sg entries are the bio itself, then the last
> > sg is the status byte.  Whether the N entries are in or out depends on
> > whether it's a read or a write.
> > 
> > We accept the normal (SCSI) ioctls: they get handed through to the other
> > side which can then handle it or reply that it's unsupported.  It's
> > not clear that this actually works in general, since I don't know
> > if blk_pc_request() requests have an accurate rq_data_dir().
> 
> They should, if they imply a data transfer.

OK, good.  We rely on that to mark input vs output sg elements.  I was
wondering if there was some weird requests which did both input and
output.

> > Although we try to reply -ENOTTY on unsupported commands, the block
> > layer in its infinite wisdom suppressed the error so ioctl(fd,
> > CDROMEJECT) returns success to userspace.
> 
> How about ever submitting a patch for that, instead of just repeatedly
> complaining about it?

To be fair, I've left the complaint in that same patch, you're just
reading it repeatedly 8)

I shall look through the code and see if I can figure out how to fix it.
I'm assuming from your response that there's not some strange reason to
preserve current behaviour.

Thanks!
Rusty.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/