Messages in this thread | | | Subject | Re: [PATCHSET] FUSE: extend FUSE to support more operations, take #2 | From | Miklos Szeredi <> | Date | Fri, 21 Nov 2008 14:29:52 +0100 |
| |
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
| |