Re: Is it time for remove (crap) ALSA from kernel tree ?

Miklos Szeredi
2007-07-01T12:19:19Z

> > 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.
>
> 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.

Thanks, but these docs are about what the ioctls do, and I'm totally
uninterested in that. What I'm interested is how the ioctl data is
_structured_.

OK, had a look at <linux/soundcard.h>, it does define a data
structuring based on the ioctl numbers, and it's just slightly
different from the structuring defined by <asm-generic/ioctl.h>. Oh,
the beauty of the ioctls.

So answering my own question: no, it's not sanely possible to support
ioctls through fuse without userspace hacks or significant effort.

A possibly acceptable option is to add a plugin mechanism, whereby
people could write small ioctl interpreter kernel modules for their
specific needs (such as parsing OSS ioctls), which would
serialize/deserialize any type of ioctl input/output making them
suitable for transfering between the kernel and the userspace
filesystem.

Another, much more complex option is to design a generic ioctl data
interpreter language, and let the filesystem upload their ioctl
parsers into the kernel.

Miklos