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
 
[an error occurred while processing this directive]
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160615124341.GA2405@localhost.localdomain>
Date:	Wed, 15 Jun 2016 14:43:41 +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,
	henrk@...tad.us, Henrik Austad <haustad@...co.com>,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	Takashi Iwai <tiwai@...e.de>, Mark Brown <broonie@...nel.org>
Subject: Re: [very-RFC 7/8] AVB ALSA - Add ALSA shim for TSN

On Wed, Jun 15, 2016 at 02:13:03PM +0200, Henrik Austad wrote:
> On Wed, Jun 15, 2016 at 01:49:08PM +0200, Richard Cochran wrote:
> And how would v4l2 benefit from this being in alsalib? Should we require 
> both V4L and ALSA to implement the same, or should we place it in a common 
> place for all.

I don't require V4L to implement anything.  You were the one wanting
AVB "devices".  Go ahead and do that, but in user space please.  We
don't want to have kernel code that sends arbitrary Layer2 and UDP
media packets.

The example you present of using aplay over the network is a cute
idea, but after all it is a trivial application.  I have nothing
against creating virtual ALSA devices (if done properly), but that
model won't work for more realistic AVB networks.

> And what about those systems that want to use TSN but is not a 
> media-device, they should be given a raw-socket to send traffic over, 
> should they also implement something in a library?

A raw socket is the way to do it, yes.

Since TSN is about bandwidth reservation and time triggered Ethernet,
decoupled from the contents of the streams, each new TSN application
will have to see what works best.  If common ground is found, then a
library makes sense to do.

At this point, it is way too early to guess how that will look.  But
media packet formats clearly belong in user space.

> So no, here I think configfs is an apt choice.
> 
> > Heck, if done properly, your layer could discover the AVB nodes in the
> > network and present each one as a separate device...
> 
> No, you definately do not want the kernel to automagically add devices 
> whenever something pops up on the network, for this you need userspace to 
> be in control. 1722.1 should not be handled in-kernel.

The layer should be in user space.  Alsa-lib *is* user space.

Thanks,
Richard

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ