On 2010-04-26, at 03:53, 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 <adilger@xxxxxxx> 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.
Exactly. The filesystem knows what the total size is including the UUID (in fact it would be better to allow the UUIDs to be variable-sized also), and userspace should be able to treat this as an opaque blob, beyond the the size.
By having userspace "decode" the file handle in order to determine the handle size, copy the pointer data, etc. then you introduce much more complexity into the whole process.
It makes me wonder if we should have some sort of "handle version" in order to allow the kernel to verify what it is being passed, in case we want to change the interface in the future.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
