All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de>
Cc: dougg@torque.net, <linux-kernel@vger.kernel.org>,
	<jens.axboe@oracle.com>, <James.Bottomley@steeleye.com>
Subject: Re: [PATCH] Block layer: separate out queue-oriented ioctls
Date: Mon, 19 Feb 2007 11:06:22 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.0702191051210.13197-100000@netrider.rowland.org> (raw)
In-Reply-To: <45d89a8b.QpxTpRwQB4A12sQN%Joerg.Schilling@fokus.fraunhofer.de>

On Sun, 18 Feb 2007, Joerg Schilling wrote:

> Alan Stern <stern@rowland.harvard.edu> wrote:
> 
> > > Alternatively the SG_GET_RESERVED_SIZE ioctl could be
> > > modified to yield no more than max_sectors*512 .
> >
> > There should be one single ioctl which can be applied uniformly to all
> > CD-type devices (in fact, to all devices using a request_queue) to learn
> > max_sectors.  This rules out using SG_GET_RESERVED_SIZE.
> 
> This has nothing to do with CD-type devices!
> It is related to SCSI tansport.

Actually, it isn't even related to SCSI transport; it is related to the
request_queue interface.  Even for devices which don't use a SCSI
transport, the request_queue code limits transfer lengths to max_sectors.

> > Furthermore, if you changed SG_GET_RESERVED_SIZE in this way you would 
> > only increase the confusion.  The reserved size isn't directly related to 
> > the maximum allowed DMA length, and there's no point pretending it is.  
> > What if it turns out that the reserved size is smaller than max_sectors?  
> > Then you'd force user programs to do I/O in chunks that were smaller than 
> > necessary.

I take back that last sentence.  If the reserved size was smaller than 
max_sectors then nothing would be changed.

> It would not increase confusion but reduce confusion because all
> programs would later behave correctly without the need to change them.

Well, if Doug wants to reduce the value returned by SG_GET_RESERVED_SIZE, 
it's okay with me.  An advantage of doing this is that older versions of 
cdrecord would then work correctly.

However you don't seem to realize that people can use programs like
cdrecord with devices whose drivers don't support SG_GET_RESERVED_SIZE --
because that ioctl works only with sg.  Programs would have to try
SG_GET_RESERVED_SIZE and if it faied, then try BLKSECTGET.

Remember also, the "reserved size" is _not_ the maximum allowed size of a
DMA transfer.  Rather, it is the size of an internal buffer maintained by
sg.  It's legal to do an I/O transfer larger than the "reserved size", but 
it is not legal to do an I/O transfer larger than max_sectors.

Alan Stern


  reply	other threads:[~2007-02-19 16:06 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-16 19:37 [PATCH] Block layer: separate out queue-oriented ioctls Alan Stern
2007-02-17  6:28 ` Jens Axboe
2007-02-17 21:18   ` Joerg Schilling
2007-02-18  3:43   ` Douglas Gilbert
2007-02-18 12:37     ` Joerg Schilling
2007-02-18 16:44     ` Alan Stern
2007-02-18 18:27       ` Joerg Schilling
2007-02-19 16:06         ` Alan Stern [this message]
2007-02-19 16:08           ` Joerg Schilling
2007-02-19 17:06             ` Alan Stern
2007-02-19 22:25               ` Douglas Gilbert
2007-02-20  3:48                 ` Alan Stern
2007-02-20  4:47                   ` Douglas Gilbert
2007-02-20 15:55                     ` Alan Stern
2007-04-26  9:19                 ` Joerg Schilling
2007-04-26 15:04                   ` Alan Stern
2007-04-26 15:08                     ` James Bottomley

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=Pine.LNX.4.44L0.0702191051210.13197-100000@netrider.rowland.org \
    --to=stern@rowland.harvard.edu \
    --cc=James.Bottomley@steeleye.com \
    --cc=Joerg.Schilling@fokus.fraunhofer.de \
    --cc=dougg@torque.net \
    --cc=jens.axboe@oracle.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.