On Fri, Sep 21 2007, Rusty Russell wrote: > 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. There very soon will be bidirectional requests with both in and out elements, but they will be clearly marked as such (and the driver needs to be marked capable). So nothing to worry about for now. > > > 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) That may be the case :-) > 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. It surely sounds like a bug, if you issue ioctl(fd, CDROMEJECT), the driver sees it and returns -ENOTTY, but userland sees a 0 retval. So if you have time, please do poke at it a bit. -- Jens Axboe _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
