Message-ID: <48B6EBBD.6050406@kernel.org>
Date: Thu, 28 Aug 2008 20:17:33 +0200
From: Tejun Heo <tj@kernel.org>
User-Agent: Thunderbird 2.0.0.12 (X11/20071114)
MIME-Version: 1.0
To: Miklos Szeredi <miklos@szeredi.hu>
CC: greg@kroah.com, fuse-devel@lists.sourceforge.net,
       linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/7] FUSE: implement ioctl support
References: <1219945263-21074-1-git-send-email-tj@kernel.org> <1219945263-21074-6-git-send-email-tj@kernel.org> <20080828175116.GB18461@kroah.com> <48B6E79E.6020702@kernel.org> <48B6E801.9080102@kernel.org> <E1KYm0D-0003q0-IQ@pomaz-ex.szeredi.hu>
In-Reply-To: <E1KYm0D-0003q0-IQ@pomaz-ex.szeredi.hu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1060
Lines: 26

Miklos Szeredi wrote:
>> If you're worried about the double copying due to performance reasons,
>> what we can do is implementing userspace to userspace copying.  I just
>> took easier path of copying twice as u-u copy can't be done using the
>> existing FUSE mechanics.
> 
> How about not copying anything in the kernel, just passing the virtual
> address to the filesystem?  It can get/modify the data of the calling
> task by mapping /proc/pid/mem.  Ugly, yes, but ioctls are inherently
> ugly.

Hmmm... I was trying to stay within similar operation mechanics as other
ops.  Directly accessing the caller's memory has performance benefits
but that benefit can also be used by reads and writes.  So, if we're
gonna do direct memory access, maybe doing it in more generic way is a
better idea?

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/