linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Kerrisk <mtk.manpages@googlemail.com>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Miklos Szeredi <miklos@szeredi.hu>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [patch] pipe: add support for shrinking and growing pipes
Date: Mon, 24 May 2010 09:28:54 +0200	[thread overview]
Message-ID: <AANLkTikwTa16lDh87zkI-L9SaI9jG1_eqZuo4z7dj2qP@mail.gmail.com> (raw)
In-Reply-To: <20100524070416.GQ23411@kernel.dk>

On Mon, May 24, 2010 at 9:04 AM, Jens Axboe <jens.axboe@oracle.com> wrote:
> On Mon, May 24 2010, OGAWA Hirofumi wrote:
>> Jens Axboe <jens.axboe@oracle.com> writes:
>>
>> >> > We can easily make F_GETPIPE_SZ return bytes, but I don't think passing
>> >> > in bytes to F_SETPIPE_SZ makes a lot of sense. The pipe array must be a
>> >> > power of 2 in pages. So the question is if that makes the API cleaner,
>> >> > passing in number of pages but returning bytes? Or pass in bytes all
>> >> > around, but have F_SETPIPE_SZ round to the nearest multiple of pow2 in
>> >> > pages if need be. Then it would return a size at least what was passed
>> >> > in, or error.
>>
>> I really think "power of 2 in pages" is simply current implementation
>> detail, not detail of pipe API.
>
> Completely agree, one more reason more to make that dependency exposed
> in the API.
>
>> >> I'd recommend this: Pass it in and out in bytes. Don't round to a
>> >> power of 2. Require the user to know what they are doing. Give an
>> >> error if the user doesn't supply a power-of-2 * page-size for
>> >> F_SETPIPE_SZ. (Again, consider the case of architectures  with
>> >> switchable page sizes.)
>> >
>> > But is there much point in erroring on an incorrect size? If the
>> > application says "I need at least 120kb of space in there", kernel
>> > returns "OK, you got 128kb". Would returning -1/EINVAL for that case
>> > really make a better API? Doesn't seem like it to me.
>>
>> FWIW, my first impression of this was setsockopt(SO_RCV/SNDBUF) of unix
>> socket. Well, API itself wouldn't say "at least this size" or "exactly
>> this size", so, in here, important thing is consistency of interfaces, I
>> think. (And the both is sane API at least for me if those had
>> consistency in the system.)
>>
>> Well, so how about set/get in bytes, and kernel will set "at least
>> specified size" actually like setsockopt(SO_RCV/SNDBUF)?
>
> Isn't that pretty much what I described?

Actually, SO_*BUF is pretty weird. It returns double what was
supplied. It's not simply a matter of rounding up: it always doubles
what was supplied.



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface" http://blog.man7.org/
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2010-05-24  7:29 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-19 16:45 [patch] pipe: add support for shrinking and growing pipes Miklos Szeredi
2010-05-19 16:49 ` Linus Torvalds
2010-05-19 18:05   ` Jens Axboe
2010-05-19 19:05     ` Jens Axboe
2010-05-20  8:33       ` Miklos Szeredi
2010-05-20  8:37         ` Jens Axboe
2010-05-20 17:42           ` Linus Torvalds
2010-05-20 17:48             ` Jens Axboe
2010-05-21 17:13               ` Rick Sherm
2010-05-23  5:30   ` Michael Kerrisk
2010-05-23  2:38     ` Andrew Morton
2010-05-23  5:52       ` Michael Kerrisk
2010-05-23  7:09         ` Jens Axboe
2010-05-23  9:24           ` Michael Kerrisk
2010-05-23 17:47             ` Jens Axboe
2010-05-24  1:43               ` OGAWA Hirofumi
2010-05-24  4:43                 ` Michael Kerrisk
2010-05-24  7:05                   ` Jens Axboe
2010-05-24  7:27                     ` Michael Kerrisk
2010-05-24 17:35                       ` Jens Axboe
2010-05-24 17:52                         ` Michael Kerrisk
2010-05-24 17:56                           ` Jens Axboe
2010-05-25  4:01                             ` Michael Kerrisk
2010-06-01  7:48                               ` Jens Axboe
2010-06-01 15:22                                 ` Linus Torvalds
2010-06-01 16:36                                   ` Loke, Chetan
2010-05-27  6:49                             ` Michael Kerrisk
2010-06-01  7:45                               ` Jens Axboe
2010-06-02 19:25                                 ` Michael Kerrisk
2010-06-03  6:10                                   ` Jens Axboe
2010-06-03  6:46                                     ` Michael Kerrisk
2010-06-03  7:01                                       ` Jens Axboe
2010-06-03  7:05                                         ` Michael Kerrisk
2010-06-03  7:48                                           ` Michael Kerrisk
2010-06-03  7:58                                             ` Michael Kerrisk
2010-06-03  8:29                                               ` Michael Kerrisk
2010-06-03  8:53                                                 ` Michael Kerrisk
2010-05-24  7:04                 ` Jens Axboe
2010-05-24  7:28                   ` Michael Kerrisk [this message]
2010-05-24  7:49                     ` OGAWA Hirofumi
2010-05-24 14:51                     ` Brian Bloniarz
2010-05-24 15:43                       ` Michael Kerrisk
2010-05-24  7:46                   ` OGAWA Hirofumi
2010-05-24 17:15                     ` Jens Axboe
2010-05-24 18:12                       ` OGAWA Hirofumi
2010-05-24 18:16                         ` Michael Kerrisk
2010-05-20 12:52 ` Andi Kleen

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=AANLkTikwTa16lDh87zkI-L9SaI9jG1_eqZuo4z7dj2qP@mail.gmail.com \
    --to=mtk.manpages@googlemail.com \
    --cc=akpm@linux-foundation.org \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=jens.axboe@oracle.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=mtk.manpages@gmail.com \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).