On Wed, 6 Dec 2006, James Bottomley wrote: > Realistically, no-one makes SCSI CDs or DVDs any more ... I know, I've > tried to get some for some of my older boxes. Most of them nowadays are > IDE attachments, which don't have a /dev/sg node. So /dev/sg is really > the legacy mode for burning. Well, there are still a lot of legacy devices out there. > The correct way to do it today is to use > the actual device name ... then you don't have to worry about what the > transport is any more. > > I could easily enough rewrite the patch to put the ioctl somewhere else > > (although I'm not quite sure exactly where would be best). But do > > non-block devices have request queues? What about the points that Doug > > raised: > > All CD/DVD burners are block devices, which is the problem set under > discussion. Fair enough. > > On Tue, 5 Dec 2006, Douglas Gilbert wrote: > > > > > Apart from sensibly yielding the max size in bytes, your patch > > > has the added benefit of allowing non-block devices (e.g. tape, > > > processor and enclosure services) to find out what limit the > > > OS/host has placed on each command's maximum transfer size. > > They all possess block queues, yes, so we should really allow access to > the block ioctls for them. > I have no idea why the block layer even implements > SG_SET_RESERVED_SIZE ... I suspect it was some legacy application > compatibility problem, so it probably can be eliminated. Let's leave that for a separate patch. It turns out that for block device files we don't need to change anything. The BLKSECTGET ioctl already does almost exactly what we want: int n; if (ioctl(fd, BLKSECTGET, &n) == 0) max_transfer_size = n * 512; So only the legacy sg character-device files need attention, which means that only the part of the patch affecting sg.c is necessary. The new SG_GET_MAX_TRANSFER_LENGTH ioctl can remain unimplemented by the block layer -- just as SG_[SG]ET_RESERVED_SIZE should be. How does that sound? Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
