> > > Not as if it would be hard to add ioctl support to fuse.  What fuse
quoted text
> > > can't handle is the data argument of ioctl(), so the most it could do
> > > is give the filesystem a pid (tid) and a virtual address.  The
> > > userspace fs could then get/put the data through /proc/<pid>/mem.
> > 
> > Hork...
> > 
> > Identify the generic ioctls that are relevant to a FUSE file system and
> > have real meaning *and* are useful.
> 
> I don't think there are any such.
> 
> The point in this thread was I think about emulating an OSS sound
> device through a fuse fs.  In that case fuse would need _generic_
> ioctl support, which simply can't be done without weird userspace
> hacks.

Well, had a look at what FUSD does.  It assumes that the ioctl
argument is stuctured according to the command.  If all OSS ioctls are
like that, then fine, fuse can support it properly.

The drawback of this is that ioctls which aren't structured properly
could cause weird failures due to wrong data being accessed by the
poor unknowing kernel.

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/