lkml.org 
[lkml]   [2008]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCHSET] FUSE: extend FUSE to support more operations, take #2
From
Date
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.

Miklos


\
 
 \ /
  Last update: 2008-11-21 14:33    [W:0.045 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site