From: Ulrich Drepper <drepper@redhat.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-api@vger.kernel.org, aarcange@redhat.com
Subject: Re: [PATCH v6 0/5] Add preadv & pwritev system calls.
Date: Fri, 16 Jan 2009 11:20:25 -0800 [thread overview]
Message-ID: <4970DDF9.4090007@redhat.com> (raw)
In-Reply-To: <200901161852.04953.arnd@arndb.de>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Arnd Bergmann wrote:
> Did you get any feedback from Ulrich
> Drepper as to whether he plans to add support to glibc?
If they are in the kernel there is no reason not to export them from
glibc. But I have a general comment about all kinds of read syscalls.
If think they have been misdesigned from day one and if we are going to
add new ones we might want to fix them.
The problem is that they don't allow for zero-copy operations in enough
cases. The kernel is not free to store the data wherever it wants even
if the userlevel code is fine with that. Ideally the program would tell
the kernel that it is fine with any addressable address and provides a
buffer for the kernel to use in case zero-copy into that buffer is
possible or no zero-copy is possible at all. An interface could look
like this:
ssize_t readz (int fd, void *buf, size_t len, void **res)
(and accordingly for similar calls). The application will then use the
pointer stored at the address pointed to by the fourth parameter instead
of unconditionally using the buffer pointed to by the second parameter.
For res==NULL the semantics could be the same as the normal read().
This is not the only interface needed to make this work. Somehow the
memory used for the zero-copy buffers has to be administrated. At the
very least an interface to mark the buffer returned by readz() as unused
is needed.
There is a lot to think about before this can be done (something I
started back in my 2006 OLS paper [1]). But I wonder whether it's worth
preparing for it and not add yet more interfaces which aren't ready for
this type of I/O.
[1] http://people.redhat.com/drepper/newni.pdf
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAklw3bIACgkQ2ijCOnn/RHSutgCgvIZki4gZfuLzwCOGkZqOf97v
1LYAn3fQj0C8CabsfvaYonFTZQ3oUtSn
=EDYF
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2009-01-16 19:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-16 16:45 [PATCH v6 0/5] Add preadv & pwritev system calls Gerd Hoffmann
2009-01-16 16:45 ` [PATCH 1/5] create compat_readv() Gerd Hoffmann
2009-01-16 16:45 ` [PATCH 2/5] create compat_writev() Gerd Hoffmann
2009-01-16 17:28 ` Arnd Bergmann
2009-01-16 16:45 ` [PATCH 3/5] Add preadv and pwritev system calls Gerd Hoffmann
2009-01-16 17:34 ` Arnd Bergmann
2009-01-16 16:45 ` [PATCH 4/5] MIPS: Add preadv(2) and pwritev(2) syscalls Gerd Hoffmann
2009-01-16 16:45 ` [PATCH 5/5] switch compat readv/preadv/writev/pwritev from fget to fget_light Gerd Hoffmann
2009-01-16 16:53 ` [PATCH v6 0/5] Add preadv & pwritev system calls Michael Kerrisk
2009-01-16 17:52 ` Arnd Bergmann
2009-01-16 19:20 ` Ulrich Drepper [this message]
2009-01-19 14:20 ` Gerd Hoffmann
2009-01-21 0:11 ` Petr Baudis
2009-01-21 9:31 ` Gerd Hoffmann
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=4970DDF9.4090007@redhat.com \
--to=drepper@redhat.com \
--cc=aarcange@redhat.com \
--cc=arnd@arndb.de \
--cc=kraxel@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox