Re: [FFADO-devel] Mixed kernelspace--userspace drivers, and current status

[Jonathan W. <jw...@ph...>]

Combining several posts ...

Clemens Ladisch wrote:
> From the interface standpoint, the best alternatives would be to have all
> the code in the kernel (using the existing ALSA interfaces), or to stay
> with the current FFADO, where all the code is in userspace (using the
> existing FireWire lowlevel interface).

I guess there's really two separate components here which - at least for
most devices - are quite separable.  The first is the streaming and the
control of that.  The second is the device control.  There's a small amount
of overlap for things like sample rate and settings which alter the number
of channels.  However, by far the largest chunk of the "control" side of
things has to do with the control of the onboard mixer which, as was said
later, has no impact on the streaming side at all.

The picture I had of all this was that the streaming stuff would go into the
kernel (perhaps along with the device control which affected streaming, so
long as a suitable kernel-userspace interface was available to provide all
such controls), with the rest of the device control remaining in userspace.
At least for the devices I deal with, this separation generally makes sense;
the mixer control doesn't *need* to be in-kernel, it's carried out generally
without any need to interact with the streaming layer at all, and would keep
a lot of complex code out of the kernel.

My interpretation of Linus's post is that the above general idea would be
acceptable.  What he would object to is if the kernel streaming engine
required action on the part of a userspace component simply to work.

> > Putting the device initialization-code into kernel-space too will
> > result in a major increase in kernelcode
> 
> Which is not a problem.  As long as it increases the robustness of the
> driver, it's preferrable.

Obviously doing so involves more complexity for some devices than others.

> Anyway, I think I should report on the current status of kernel
> streaming, and where it's going.
> :

Thanks for this update.

> 3) Fireworks (Echo), and
> 4) DICE: these drivers are in development. ...
>    :
>    I expect to have nailed down the device-specific API of these drivers
>    shortly.
> 
> As for future drivers:  RME and MOTU drivers cannot reuse the AMDTP
> code, but should otherwise be similar to the Fireworks/DICE drivers.

So I guess the sensible thing for me to do here is to use either the
Fireworks or DICE drives as a sort of guide when implementing RME/MOTU
support.  That sounds fine to me.  Do you have any feeling as to when these
drivers might be in a condition which gives me a reasonably accurate idea of
how things should be structured?  Will that be when you merge them to ALSA,
or should I grab them earlier?  And if the latter, how is this to be done (I
presume it's in a git repo somewhere).

> Reporting of control changes requires some new API (like the DICE
> notifications), but falls under Linus' second point ...

Agreed.

Clemens Ladisch wrote:
> Arnold Krille wrote:
> > On Thursday 10 March 2011 13:18:40 Clemens Ladisch wrote:
> > > AV/C devices cannot be handled this easily; "user space helps kernel"
> > > is exactly what was proposed.  I'm wondering if it is possible for the
> > > driver to detect (only) the current configuration, and to let userspace
> > > notify it when the configuration was changed.
> > 
> > But the kernel will "see" the changes much earlier because the streaming will
> > not work correctly. Waiting then for user-space to notify about the changes
> > sounds dangerous.
> 
> I mentioned the DICE driver's "lock" ioctl that must be used by
> userspace to prevent the driver from streaming while 'dangerous'
> configuration changes are being made; the same will be applicable here.

Yes.  At least for RME/MOTU, a simple lock along these lines should cover
all situations I would have to deal with.

From: Stefan wrote:
> I suppose sync does change indeed.  At least the Linux node did not
> transmit between PM suspend and resume, and from the driver's POV there
> was a jump in bus time and real time. ... Device state could have changed.

Yes.  But topology could also have changed and this may affect sync for some
devices.  So really after a suspend things really have to be reinitialised
from scratch anyway.

> But take for example firewire-sbp2:  It assumes that it can simply go on
> using any storage device that is still there after resume and accepted the
> re-login.  If the user or a concurrent SBP-2 initiator modified the
> device's store or other state between suspend and resume, he presumably
> knew what he was doing.

Making an analogy to firewire audio devices, the "re-login" would be
equivalent to configuring the device as we want it to be.  Firewire audio
devices do not generally support anything like SBP-2's concurrent
initiators, so that's not really a practical problem.  The reason why device
configuration could have changed is that quite a few devices have front
panel controls which can be used to change device settings, and some devices
don't even power up in the same state they were in when powered off.

But I don't see any of this being a major problem though - so long as the
situation is understood by us we can code accordingly.  Although I haven't
looked into it in any great detail, I haven't yet seen an incompatibility
between this requirement and the API separations being proposed.

Regards
  jonathan