From: Tejun H. <tj...@ke...> - 2008-11-21 14:37:39
|
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 |