[alsa-devel] Future of the HDA driver

[Takashi Iwai]

At Mon, 03 Oct 2011 16:04:46 +0200,
Jaroslav Kysela wrote:
> 
> Date 3.10.2011 14:27, Takashi Iwai wrote:
> > At Mon, 03 Oct 2011 14:01:00 +0200,
> > David Henningsson wrote:
> >>
> >> Hi Takashi etc,
> >>
> >> 1) I think it would make sense to have a designated time and room for a 
> >> "future of HDA" discussion in Prague. We could e g discuss input jacks 
> >> as kcontrols, and exposing routing to user space, as IIRC Mark Brown was 
> >> suggestion earlier. What do you think?
> > 
> > Sure, we can hold a meeting spontaneously, as this would be for
> > smaller group.  The sound BoF isn't exactly scheduled at all yet.
> > I don't know how many guys will be there, so I thought it can be
> > managed spontaneously by announcing on the message board there or so.
> 
> I'll be there (LinuxCon), so you may count me in.

Good to hear!

> To this topics: For some months, I play with an idea to move the whole
> HDA configuration stuff outside the kernel and leave in kernel just
> mandatory things like the HDA controller code and a library with
> functions for the user space code.
> 
> Because it's a bit nonsense to start with something totaly new when we
> have a good C codebase with hw descriptions. I looked around the net for
> a simple, small C compiler and it seems that TCC (www.tinycc.org) is
> ideal for this purpose.
> 
> I created own instruction 32/64-bit set (C optimized) and I'm now at the
> point that I can compile the HDA code to this instruction set with
> special TCC version and I have a simple disassembler to figure the
> compilation/linking issues.
> 
> The ELF loader and instruction parser is also quite complete. but a lot
> of work is missing especially to create the in-kernel library for all
> stuff which is required from the codec description code (kcontrol,
> procfs interface etc.). Also, the codec specific source code should not
> use some in-kernel things directly, but via macros or in-line helpers.
> 
> The end result should be "one universal kernel driver and firmware files
> describing the codecs". The possibility to compile the codec specific
> source code directly in the kernel should be retained and the source
> code between build-in driver codes and firmware codes should be shared.
> 
> I hope that you like this idea like me. All opinions are welcome. We may
> discuss this idea in Prague. I can post my work somewhere for further
> discussion or collaborative development.

As David already wrote, moving a big stuff into user-space is nice in
one side.  I fully agree, too.  And, the techniques you described in
the above sounds pretty interesting, makes me curious about the
detailed implementation.  But, it's a different question whether this
would be accepted as the standard.

First off, the biggest concern in this approach is the extra step user
need.  In general, moving configuration to user-space from the device
driver tends to fail.  You might remember the attempt of em28xx
TV-tuner driver, or such examples.  It's mostly because the extra step 
and lost sync of code control from the kernel tree lead to more
burden for users, even for distros.

Another big concern is that you'll run a native code in kernel-space.
Such a support is unlikely welcome into the kernel tree, no matter how
you say it must be safe.

Lastly, there is no much need of specific "firmware" nowadays in most
cases.  The most of the parser code can be shared by each codec, and
the difference between codec drivers would become minimum in the end.
If so, there is no need for loading some codes dynamically.  You can
simply use a module as of now.

Anyway, the technique sounds interesting, as mentioned, so let's keep
discussions.


thanks,

Takashi