this is not needed, f_flags are already passed to userspace for read
and write.
0004-FUSE-implement-direct-lseek-support.patch
this is trickier to get the interface right I think. If we want to
allow filesystems to implement a custom lseek, then we also want them
to keep track of the file position, which means we must differentiate
between a write(2) and a pwrite(2) and similarly for reads. AFAICS
this isn't needed for CUSE so we can leave this to later.
This would be nice, but... I don't really like the fact that it uses
the file handle. Could we have a separate "poll handle" that is
returned in the POLL reply?
> 1. I'll try to incorporate all other comments here but regarding ioctl I
I still got qualms about this ioctl thing. One is the security
aspect, but that could be dealt with. The other is that I really
really don't want people to start implementing new custom ioctls for
their filesystems, as I think that way lies madness. We could limit
ioctls to CUSE and that would be fine with me. Or for non-CUSE users
we could enforce the "standard" format where the type and length is
encoded in the command number.
I don't have any problems with the iterative way you implemented
ioctls. We just need some additional restrictions to the current
implementation, I think.
> 2. You told me that the version branching in the userland library wasn't
The version number has to be bumped anyway. But if you are only
adding new functions to the end of fuse_operations and
fuse_lowlevel_ops, then the interface can handle that, without needing
new compatibility functions.
> 3. Any other things on you mind?
One other thing I was thinking about is that do we really need
emulated char devices to be char devices? What I mean is, what would
happen if instead of a char device /dev/dsp would be a regular file
mounted on /dev/dsp (which implements all the necessary interfaces:
ioctls, poll, etc)?
