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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 01 Jul 2007 14:17:08 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	mista.tapas@....net
CC:	alan@...rguk.ukuu.org.uk, bunk@...sta.de, nix@...eri.org.uk,
	galibert@...ox.com, tiwai@...e.de, kloczek@...y.mif.pg.gda.pl,
	linux-kernel@...r.kernel.org
Subject: Re: Is it time for remove (crap) ALSA from kernel tree ?

> > 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/