From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Aneesh Kumar K. V" Subject: Re: [PATCH -V4 6/6] x86: Add new syscalls for x86_64 Date: Tue, 27 Apr 2010 11:55:34 +0530 Message-ID: <87r5m14dk1.fsf@linux.vnet.ibm.com> References: <1272022715-11716-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <1272022715-11716-7-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <7FF35E15-2BA8-4EEB-8F48-13E92E510947@sun.com> <87hbmz1j4l.fsf@linux.vnet.ibm.com> <20100426095311.GB23020@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andreas Dilger , hch@infradead.org, viro@zeniv.linux.org.uk, corbet@lwn.net, serue@us.ibm.com, linux-fsdevel@vger.kernel.org, sfrench@us.ibm.com To: Christoph Hellwig Return-path: Received: from e28smtp02.in.ibm.com ([122.248.162.2]:56052 "EHLO e28smtp02.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751202Ab0D0GZm (ORCPT ); Tue, 27 Apr 2010 02:25:42 -0400 Received: from d28relay03.in.ibm.com (d28relay03.in.ibm.com [9.184.220.60]) by e28smtp02.in.ibm.com (8.14.3/8.13.1) with ESMTP id o3R6PcDM025754 for ; Tue, 27 Apr 2010 11:55:38 +0530 Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o3R6Pceh2232328 for ; Tue, 27 Apr 2010 11:55:38 +0530 Received: from d28av03.in.ibm.com (loopback [127.0.0.1]) by d28av03.in.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o3R6PbLC001257 for ; Tue, 27 Apr 2010 16:25:38 +1000 In-Reply-To: <20100426095311.GB23020@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, 26 Apr 2010 05:53:11 -0400, Christoph Hellwig wrote: > On Sun, Apr 25, 2010 at 11:58:58PM +0530, Aneesh Kumar K. V wrote: > > On Fri, 23 Apr 2010 16:09:07 -0600, Andreas Dilger wrote: > > > On 2010-04-23, at 05:38, Aneesh Kumar K.V wrote: > > > > Add necessary compat syscall support > > > > > > Maybe I'm missing something, but why would we add a new syscall that immediately needs a compat interface? I thought the kernel would simply return the packed file handle to userspace, instead of returning a pointer? > > > > > > > +struct compat_file_handle { > > > > + int handle_size; > > > > + int handle_type; > > > > + /* File system identifier */ > > > > + struct uuid fsid; > > > > + /* file identifier */ > > > > + compat_uptr_t f_handle; > > > > +}; > > > > > > > > > I want to make sure we put uuid part of the fs as a separate member. I > > guess we could avoid compat interface if we define the syscall as > > > > open_by_handle(struct file_handle *handle, int size, int flags); > > > > But the handle in the above case will not be usable if the file handle > > returned is too big to be usable by a cluster file system because of the > > UUID part of handle. Having uuid as a seperate member allows such userspace > > to generate a smaller unique identifier for the filesystem and still use > > the void *f_handle part of the struct file_handle. > > > > With struct file_handle since we have void * usage i guess we would need > > a compat interface. > > You can juse make the handle a > > char f_handle[0]; > > member and the structure variable size. > Even with the above change i guess we would need a compat_sys_open_by_handle to make sure we don't pass O_LARGEFILE similar to what is done in compat_sys_open -aneesh