Hi Tejun,

On Tue, 14 Oct 2008, Tejun Heo wrote:
quoted text
> Hello, Miklos.
> 
> I'm about ready to send the next round of this patchset w/ mmap support,
> which I'm sure gonna stir up some discussion. :-) Several things I wanna
> hear your comments about.

Great.  Just yesterday evening I was looking through your patches to
see which ones I can submit for 2.6.28, and I've already applied

  0001-FUSE-add-include-protectors.patch
  0003-FUSE-implement-nonseekable-open.patch

Comments about the others:

  0002-FUSE-pass-nonblock-flag-to-client.patch

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.

  0005-FUSE-implement-ioctl-support.patch

See below.

  0006-FUSE-implement-unsolicited-notification.patch
  0007-FUSE-implement-poll-support.patch

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?

quoted text
> 1. I'll try to incorporate all other comments here but regarding ioctl I
> don't think we've reached any better solution, so I'm sticking with the
> original one.

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.

quoted text
> 2. You told me that the version branching in the userland library wasn't
> necessary.  Can you explain to me when FUSE version bumping is necessary?

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.

quoted text
> 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)?

Thanks,
Miklos
--
unsubscribe notice
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/