linux-kernel - Re: [very-RFC 0/8] TSN driver for the kernel

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:	Tue, 14 Jun 2016 20:26:15 +0200
From:	Richard Cochran <richardcochran@...il.com>
To:	Henrik Austad <henrik@...tad.us>
Cc:	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	alsa-devel@...r.kernel.org, netdev@...r.kernel.org,
	Arnd Bergmann <arnd@...aro.org>
Subject: Re: [very-RFC 0/8] TSN driver for the kernel

On Tue, Jun 14, 2016 at 11:30:00AM +0200, Henrik Austad wrote:
> So loop data from kernel -> userspace -> kernelspace and finally back to 
> userspace and the media application?

Huh?  I wonder where you got that idea.  Let me show an example of
what I mean.

	void listener()
	{
		int in = socket();
		int out = open("/dev/dsp");
		char buf[];

		while (1) {
			recv(in, buf, packetsize);
			write(out, buf + offset, datasize);
		}
	}

See?

> Yes, I know some audio apps "use networking", I can stream netradio, I can 
> use jack to connect devices using RTP and probably a whole lot of other 
> applications do similar things. However, AVB is more about using the 
> network as a virtual sound-card.

That is news to me.  I don't recall ever having seen AVB described
like that before.

> For the media application, it should not 
> have to care if the device it is using is a soudncard inside the box or a 
> set of AVB-capable speakers somewhere on the network.

So you would like a remote listener to appear in the system as a local
PCM audio sink?  And a remote talker would be like a local media URL?
Sounds unworkable to me, but even if you were to implement it, the
logic would surely belong in alsa-lib and not in the kernel.  Behind
the enulated device, the library would run a loop like the example,
above.

In any case, your patches don't implement that sort of thing at all,
do they?

Thanks,
Richard