From: Zach Brown <zach.brown@oracle.com>
To: Nick Piggin <npiggin@suse.de>
Cc: Nate Diller <nate.diller@gmail.com>,
Christoph Hellwig <hch@infradead.org>,
Linux Filesystems <linux-fsdevel@vger.kernel.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [patch 1/3] fs: add an iovec iterator
Date: Fri, 9 Feb 2007 12:28:06 -0500 [thread overview]
Message-ID: <A45C279B-2105-4FDA-9C14-E37158858176@oracle.com> (raw)
In-Reply-To: <20070209033133.GA18400@wotan.suse.de>
> What I have there is not actually a full-blown file io descriptor,
> because
> there is no file or offset. It is just an iovec iterator (so maybe
> I should
> rename it to iov_iter, rather than iodesc).
>
> I think it might be a nice idea to keep this iov_iter as a standalone
> structure, and it could be embedded into a struct file_io?
Yeah, maybe.
I'm not sure we need something as generic as a "file_io" struct.
To recap, I've hoped for the expression of the state of an iovec
array with a richer structure to avoid the multiple walks of the
array at different parts of the kernel that previously only had
access to the raw iovec * and size_t count.
Stuff like the alignment checks in __blockdev_direct_IO() and the
pages_in_io accounting in direct_io_worker().
I imagined building up the state in this 'iodesc' structure as we
first copied and verified the structure from userspace. (say in
rw_copy_check_uvector()).
If as we copied we, say, stored in the bits of the buffer and length
fields then by the time we got to __blockdev_direct_IO() we'd just
test the bits for misalignment instead of iterating over the array
again.
It starts to get gross as some paths currently modify the kernel copy
of the array as they process it :/.
- z
next prev parent reply other threads:[~2007-02-09 17:28 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-08 13:07 [rfc][patch 0/3] a faster buffered write deadlock fix? Nick Piggin
2007-02-08 13:07 ` [patch 1/3] fs: add an iovec iterator Nick Piggin
2007-02-08 19:49 ` Christoph Hellwig
2007-02-09 1:46 ` Nick Piggin
2007-02-09 2:03 ` Nate Diller
2007-02-09 3:31 ` Nick Piggin
2007-02-09 17:28 ` Zach Brown [this message]
2007-03-09 10:40 ` Christoph Hellwig
2007-02-08 23:04 ` Mark Fasheh
2007-02-08 13:07 ` [patch 2/3] fs: introduce perform_write aop Nick Piggin
2007-03-09 10:39 ` Christoph Hellwig
2007-03-09 12:52 ` Nick Piggin
2007-03-09 22:01 ` Anton Altaparmakov
2007-03-09 23:33 ` Mark Fasheh
2007-03-10 9:25 ` Christoph Hellwig
2007-03-12 2:13 ` Mark Fasheh
2007-03-14 13:30 ` Nick Piggin
2007-03-14 15:17 ` Christoph Hellwig
2007-02-08 13:07 ` [patch 3/3] ext2: use " Nick Piggin
2007-02-08 14:47 ` Dmitriy Monakhov
2007-02-09 19:14 ` Andrew Morton
2007-02-09 19:45 ` Andrew Morton
2007-02-10 1:34 ` Nick Piggin
2007-02-10 1:50 ` Andrew Morton
2007-02-09 0:38 ` [rfc][patch 0/3] a faster buffered write deadlock fix? Mark Fasheh
2007-02-09 2:04 ` Nick Piggin
2007-02-09 8:41 ` Andrew Morton
2007-02-09 9:54 ` Nick Piggin
2007-02-09 10:09 ` Andrew Morton
2007-02-09 10:32 ` Nick Piggin
2007-02-09 10:52 ` Andrew Morton
2007-02-09 11:31 ` Nick Piggin
2007-02-09 11:46 ` Andrew Morton
2007-02-09 12:11 ` Nick Piggin
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=A45C279B-2105-4FDA-9C14-E37158858176@oracle.com \
--to=zach.brown@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nate.diller@gmail.com \
--cc=npiggin@suse.de \
/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.