All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Douglas Gilbert <dougg@torque.net>
Cc: Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de>,
	<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 22:48:08 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.0702192238110.4237-100000@netrider.rowland.org> (raw)
In-Reply-To: <45DA23C7.6090800@torque.net>

On Mon, 19 Feb 2007, Douglas Gilbert wrote:

> Alan,
> The SG_GET_RESERVED_SIZE ioctl is also defined in
> the block layer, see block/scsi_ioctl.c .

Ah, I didn't know that.  (Or more likely, I used to know and have since 
forgotten.)  Thanks for pointing it out.

> I suspect it is just a kludge to fool cdrecord that it
> is talking to a sg device. [One of many kludges in the
> block SG_IO ioctl implementation to that end.]
> So perhaps the block layer versions of SG_SET_RESERVED_SIZE
> and SG_GET_RESERVED_SIZE need to be similarly capped.

Yes.  In fact one of them already is, but the other should be too.

> Actually I think that I would default SG_GET_RESERVED_SIZE to
> request_queue->max_sectors * 512 in the block layer
> implementation (as there is no "reserve buffer" associated
> with a block device).

Okay.

Come to think of it, the reserved_size value used when a new sg device is
created should also be capped at max_sectors * 512.  Agreed?  I can't see
any reason for ever having a larger buffer -- it would be impossible to
make use of the extra space.

Alan Stern


  reply	other threads:[~2007-02-20  3:48 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
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 [this message]
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.0702192238110.4237-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.