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

[Florian Schmidt]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/