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:	Fri, 29 Jun 2007 18:14:28 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	alan@...rguk.ukuu.org.uk
CC:	mista.tapas@....net, 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 ?

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