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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
