Re: [FFADO-devel] Mixed kernelspace--userspace drivers

[Stefan R. <st...@s5...>]

On Mar 09 Arnold Krille wrote:
> Hi,
> 
> On Wednesday 09 March 2011 17:20:18 Adrian Knoth wrote:
> > On 03/07/11 20:51, Stefan Richter wrote:
> > > there is a brief and general discussion of the merits of userspace vs.
> > > kernelspace vs. mixed space drivers in an LKML posting of today by Linus:
> > > https://lkml.org/lkml/2011/3/7/270
> > > For obvious reasons I thought to bring it up here :-) although similar
> > > things have been said here already.
> > This is a rather clear statement, and Linus obviously doesn't like the
> > approach "we" take atm with in-kernel streaming and userspace device
> > setup.
> > 
> > So my understanding of the mail is: Linus wants us to move the device
> > initialization code to the kernel, too.
> 
> I think there are other possible ways:
> 
>  - Lighten the kernel-streaming code to an absolut minimum, basically just 
> some memory accessible from userspace but also filled/read by the kernel or the 
> device via dma.

It is actually a grey area, not a black-white issue.  Userspace-only
device drivers do not actually exist; there can only be kernelspace-only
drivers or mixed kernelspace + userspace drivers.  In the latter case, the
ways how kernelspace and userspace interact is a grey area too.

Linus mentioned as one example what kind of interaction to avoid is when
userspace needs to react after PM suspend/resume cycle.  This is hard
enough to do race-free in kernelspace; having userspace critically
involved in this would be a rather broken design.  To extend this example
to audio drivers:  In the desktop audio domain, suspend/resume should
surely be fully transparent to userspace --- whereas in the studio/stage
audio domain, it is probably acceptable if a suspend/resume cycle looks to
userspace like a plugout/plugin cycle or other I/O interruption by the
device.

The major point though is that people need to be able to upgrade or
downgrade kernel and userland independently of each other.  If somebody
wants to use device XY, he needs of course versions of kernel and
userland that respectively provide the necessary features for that device 
and have the relevant bugs fixed.  But other than the need to have
sensible minimum versions, there must be no version interdependence.

From that (and from security considerations) follows that ad-hoc interfaces
between kernel and userland are not acceptable; they need to be long-term
stable, preferably general, and rather platform agnostic.  Which is a big
liability.

Consider the firewire-cdev interface:  The good thing is, it is
architecturally very much the same as the in-kernel interface between
firewire-core and application-layer drivers.  Alas, unlike this latter
interface, firewire-cdev is supposed to be a stable ABI (stable as in
backwards and forwards compatible), and it must enable userland to apply
access policies.

So, the fewer and the simpler the interfaces between kernel and userspace
are, the better --- to state the very obvious.

>  - Include the kernel-module in the userspace app and put it in the kernel via 
> dkms. That is "do what you need to but don't think about separating kernel-
> module and userspace-tools".

The capabilities of DKMS notwidthstanding, please forget right away any
scenario that involves kernel components whose source is managed outside
the kernel repository or which are not distributed with kernel packages.

> Putting the device initialization-code into kernel-space too will result in a 
> major increase in kernelcode and also contain lots of workarounds for different 
> devices. And I think that is not wanted either...

I understand Linus' general opinion on when to put stuff into userspace is
not a question of "Can it be done in userspace?" but "Can it be done
simpler in userspace?", considering implementation, maintenance,
deployment, usage.  Now, the thing is, since there can't be sole userspace
device drivers, putting something into userspace involves (a) using an
existing kernel interface or (b) extending an existing one or (c) having to
invent a new one.  Clearly, (a) but much more so (b) and (c) tend to make
things more difficult rather than simpler.  So maybe the question is even
"Really?  Are you that sure that it can be done simpler in userspace, all
things considered?". :-)

Anyway; who am I to comment?  I only know kernelspace and I am very
unfamiliar with audio I/O requirements and the apparently wondrously
diverse world of audio device control.
-- 
Stefan Richter
-=====-==-== --== -=--=
http://arcgraph.de/sr/