Message-ID: <4926C7A4.7020605@kernel.org>
Date: Fri, 21 Nov 2008 23:37:24 +0900
From: Tejun Heo <tj@kernel.org>
User-Agent: Thunderbird 2.0.0.17 (X11/20080922)
MIME-Version: 1.0
To: Miklos Szeredi <miklos@szeredi.hu>
CC: linux-kernel@vger.kernel.org, fuse-devel@lists.sourceforge.net
Subject: Re: [PATCHSET] FUSE: extend FUSE to support more operations, take
 #2
References: <1227190298-4585-1-git-send-email-tj@kernel.org> <E1L3G3Q-0006SJ-Uc@pomaz-ex.szeredi.hu> <49268876.7080303@kernel.org> <E1L3Tp0-0007dc-3S@pomaz-ex.szeredi.hu> <4926B251.6010109@kernel.org> <E1L3W52-0007t3-PZ@pomaz-ex.szeredi.hu>
In-Reply-To: <E1L3W52-0007t3-PZ@pomaz-ex.szeredi.hu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2147
Lines: 46

Miklos Szeredi wrote:
> On Fri, 21 Nov 2008, Tejun Heo wrote:
>> Miklos Szeredi wrote:
>>> On Fri, 21 Nov 2008, Tejun Heo wrote:
>>>>> I removed ->unrestricted_ioctl() and associated code because it really
>>>>> doesn't make any sense: the high level lib won't be used for CUSE
>>>>> stuff, otherwise unrestrited ioctls are not allowed (and the interface
>>>>> is rather horrible anyway).
>>>> Well, CUSE highlevel interface piggy backs on FUSE so it requires
>>>> unrestricted_ioctl() there for it and ossp does use it.
>>> I thought it uses the lowlevel interface.  Why doesn't it do that?
>> Well, because it's simpler that way and people would be more used to it?
>>  It's just easier when you implement a method which returns something
>> and looks similar to the respective file operation.
> 
> Ah, that.  Yeah, it's more intuitive, but that comes at a price.  I'm
> not sure that for CUSE it's worth it.  As I said the biggest feature
> is having paths, the others are not that important (like allocating a
> buffer for read, that's really not too complex to do in each CUSE
> driver).
> 
>>> For CUSE there's really no point in going through high level
>>> interface, since there's just one file involved, so the path name
>>> generation (the main feature of the highlevel lib) doesn't make any
>>> sense.
>> Well, the choice was mostly for convenience as there also are a few
>> places where high level interface wraps things better a bit.  Converting
>> wouldn't be difficult.  Do you think it's important?  I think keeping
>> things as parallel to FUSE as possible is more important.
> 
> I wouldn't care very much, if it weren't for that horrid
> unrestricted_ioctl().  Not your fault, the interface is just not well
> suited to that.

If you want drop highlevel CUSE interface, that's fine with me.  After
all, the complexity difference isn't that big for CUSE anyway.

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/