Message-ID: <CAF_S4t8gG_28+XYEEUz1=NbA7LqULTByzP93iTE=J927xzYyWg@mail.gmail.com>
Date:	Sun, 14 Aug 2011 14:36:19 -0400
From:	Bryan Donlan <bdonlan@...il.com>
To:	Rein Kadastik <pocketpower@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Different concept for drivers?

On Sun, Aug 14, 2011 at 08:07, Rein Kadastik <pocketpower@...il.com> wrote:
> Hi,
>
> Had this idea in my head for a long time and maybe some less lazy
> programmer here will catch on and implement few of the following ideas
> about Linux driver concepts.
>
> It all began when I reviewed ALSA soundcard drivers searching the way
> to support then malfunctioning ESI MAYA44 soundcard (which is
> currently working but dirver was not done by me). What I discovered
> was that 95% of all the drivers I went through were EXACTLY the same.
> I mean they contained immense amount of identical functionality -
> hardware protocol implementations, registry communications etc. But
> the problem I saw was that different driver authors reinvented the
> wheel at different level of correctness and some implementations were
> clean and some were plain ugly. The only reason they reimplemented the
> logic was because the variables had different values - the registry
> numbers and the meanings of bits were different.

That sounds like the common code should be made shared across the ALSA
drivers in question...

> So I started to think about what the driver is and came up with an idea:
>
> ===> Idea <===
> For hardware to work, there must be an engine that is capable of
> operating the hardware given the hardware description exists. That
> engine should be part of the kernel or a userland daemon, written once
> and available for anybody to use. The hardware description however
> should be concern of driver developers - that description would become
> the driver.
> ===> End of idea <===

... but this is not such a good idea. You'd basically have to make an
entirely new programming language, one just as powerful as C. And it
would need to perform as well as C to be accepted.

>
> Let me give you a simple example of my point:
>
> Each and every audio card has number of channels 2-n and each and
> every card has the capability to mute individual channels by flipping
> some bits. Current audio drivers contain both the flipping logic as
> well as the hardcoded values of the registers and the bits to flip and
> for each card the values differ while the bit flipping logic remain
> constant ( although due different level of logical thinking capability
> of different developers result in very weird implementations of the
> same simple logic). But what about an engine that contains logic:
>
> To mute audio in channel X, you need to flip the bit Y in registry Z
>
> And then we have description for the specific audio card where it is written:
>
> ...
> Registry: 12; Bit: 3; Feature: Mute channel 1
> Registry: 12; Bit: 4; Feature: Mute channel 2
> ...

This is nice and simple, but not all operations involve just a single
hardware register bit. With some devices you might need to write to
multiple registers in a specific order. You might need to prepare a
packet to be sent across a bus internal to the device. You need to be
able to detect and handle error conditions; some of these conditions
might require retries, or trying a different approach entirely.

Once you start handling all of this, you end up with something very
similar to C - you have if statement, you have loops, you'll probably
need to be able to allocate memory for some operations, you definitely
need to be able to control locking. But you also need to write all the
bindings to allow this new hardware description language to call into
C (and be called from C), and you need to write the compiler to
convert it to a C driver (or an interpreter, but kernel developers are
likely to frown upon interpreter overhead).

> Security aspect: As the critical coding part would be single entity
> and drivers will not contain any code, there would not be possible to
> introduce security risk into the system or the driver would not be
> able to bring the system down. The engine would be verified code that
> simply parses the descriptions and behaves as understood from the
> description.

It's all too easy to introduce security vulnerabilities into the
hardware description as well :) Sound cards perform DMAs, after all -
if you can get them to DMA to the wrong memory addresses you might
manage to read or overwrite sensitive data. Sure, you could avoid some
classes of issues (buffer overruns, perhaps), but at  what cost?

> One more thing. If we have the working description for such an engine
> on one platform and that engine would be ported to different platform,
> the hardware would magically start working there as well. I mean, the
> registries and their meanings remain the same no matter what OS you
> have installed. So the hardware description remain the same and only
> the OS specific parts would change but that would be the concern of
> engine developers.

LWN has an interesting article on the costs of abstraction layers:
http://lwn.net/SubscriberLink/454716/acf6d97d36960ead/
Basically, you're limiting yourself to the lowest common denominator
of OS functionality there, so at the very least you're losing
performance, and probably functionality as well.

> Engines would be specific to hardware category, like soundcard engine
> and network interface card engine and storage controller engine etc,
> that will understand specific descriptions and have implementations to
> operate specific kind of hardware.

And now we need multiple programming languages, one for each type of device?

> Damn, the world would be nice but mybe I am missing something here :)

To summarize, your proposal boils down to a DSL (Domain Specific
Language) for writing hardware drivers. I'm not convinced you can do
much better than C for this, however. Many of your proposed features
can be implemented in C with appropriate library code - eg, you could
write a layer that binds mute and volume settings to specific hardware
registers; it could take a static table to define the bindings, and
then drivers could just call into it. This, of course, assumes there
are enough devices with such a simple volume control method that this
is worth it.

I do think that this could be an interesting research project, but
finding good abstractions like this is _very_ difficult, and finding
one that does not make maintenance and improvements for the kernel at
large more difficult is even harder. If you do decide to tackle this,
I would recommend treating it as an extension to C to simplify common
tasks, rather than an entirely new language in itself.

>
> As I feel, I am still not ready to join the high-volume LKML, I would
> like to have replies to this post CC-d to: pocketpower@...il.com

Filter LKML posts to a label, gmail's not going to fill up :) That
said, don't worry - it's normal etiquette on LKML to CC all posters in
a thread by default (ie, use reply to all).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists