linux-kernel - Re: Different concept for drivers?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMOZ1BusP7=u6zP+0WL2fW0fD8B9YDmD9sRrR3HXnVBsSQ7Jxg@mail.gmail.com>
Date:	Sun, 14 Aug 2011 23:53:50 +0000
From:	Michael Witten <mfwitten@...il.com>
To:	Bryan Donlan <bdonlan@...il.com>
Cc:	Rein Kadastik <pocketpower@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: Different concept for drivers?

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