Different concept for drivers?

Different concept for drivers?

[Rein Kadastik]

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.

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 <===

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
...

So in this way we could DESCRIBE all the features and capabilities of
the particular piece of hardware WITHOUT writing a single line of
code. The coding part would be written once as the part of the kernel
and the correct description would be selected by PCI ID-s for example
which could even be fetched over the network if desired. That way we
could improve the quality of the drivers SO MUCH.

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.

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.

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.

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

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@gmail.com

--
Thank you!
Rein Kadastik

Re: Different concept for drivers?

[Bryan Donlan]

On Sun, Aug 14, 2011 at 08:07, Rein Kadastik <pocketpower@gmail.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@gmail.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).

Re: Different concept for drivers?

[Michael Witten]

On Sun, Aug 14, 2011 at 18:36, Bryan Donlan <bdonlan@gmail.com> wrote:
> 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.

That's really the crux of the issue.

As long as critical code may still easily lift the veil of abstraction
(in well-defined ways!) and tinker around by hand in order to achieve
optimal performance and implement special features, then some kind of
abstraction layer could indeed be very useful in propagating code
quality for at least the lowest common denominator of functionality.

However, it seems more appropriate to provide an API rather than
various DSLs/VMs.