On Friday 29 June 2007, Miklos Szeredi wrote: > > > > Not as if it would be hard to add ioctl support to fuse. What fuse > > > > 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
Included with the docs there's a list of the OSS ioctls. I don't understand enough of the problem to judge whether they are suitable to be handled by FUSE: http://manuals.opensound.com/developer/ioctl.html [version 4] http://www.4front-tech.com/pguide/oss.pdf [version 3] I don't know which API version is supposed to be supported though. Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/