From: Ben Dooks <ben-linux@fluff.org>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Mitch Bradley <wmb@firmworks.com>,
Nicolas Pitre <nico@fluxnic.net>,
devicetree-discuss <devicetree-discuss@lists.ozlabs.org>,
linuxppc-dev <linuxppc-dev@ozlabs.org>,
microblaze-uclinux@itee.uq.edu.au,
Olof Johansson <olof@lixom.net>,
Dan Malek <ppc6dev@digitaldans.com>,
Jeremy Kerr <jeremy.kerr@canonical.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: Request review of device tree documentation
Date: Mon, 14 Jun 2010 21:00:00 +0100 [thread overview]
Message-ID: <20100614200000.GB7248@trinity.fluff.org> (raw)
In-Reply-To: <AANLkTimc12G-YYTd4yQiviY-ijvJ9TzVEmxxaoF43xVR@mail.gmail.com>
On Sun, Jun 13, 2010 at 11:36:57PM -0600, Grant Likely wrote:
> On Sun, Jun 13, 2010 at 2:29 AM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Sat, 2010-06-12 at 20:45 -1000, Mitch Bradley wrote:
> >
> >> Either fought or embraced. To the extent that it is possible to focus
> >> solely on Linux and ARM, one could image doing a good HAL.
> >
> > That will come with a huge amount of comunity resistance sadly, but I
> > can imagine distros liking it.
> >
> > In general, I much prefer having all the necessary native drivers in the
> > kernel, and the device-tree to provide the right representation, and
> > avoid trying to abstract "methods" via a HAL. It's the Linux philosophy
> > as much as possible (even when defeated by ACPI).
> >
> > But if we're going to be forced by vendors into HALs, we can also make
> > sure that whatever they come up with is half reasonable :-)
>
> I think there is more to be concerned about regarding binary blobs
> than HALs. Many of the new SoCs require closed binaries to use all
> the hardware right now (graphics cores in particular).
>
> Board vendors seem to be taking the plunge and modifying the kernel
> rather than trying to create a HAL for driving board specific
> features.
In my view HALs are a bad idea, they constrain you to one calling method
and make it difficult to evolve support in the kernel. I belive it is
part of the reason that we've always tried to avoid a standardised
kernel driver interface.
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
next prev parent reply other threads:[~2010-06-14 20:15 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-11 22:59 Request review of device tree documentation Grant Likely
2010-06-11 23:47 ` Dan Malek
2010-06-12 2:58 ` Benjamin Herrenschmidt
2010-06-12 4:48 ` Mitch Bradley
2010-06-12 6:53 ` Grant Likely
2010-06-12 8:19 ` Mitch Bradley
2010-06-12 10:45 ` Benjamin Herrenschmidt
2010-06-12 10:48 ` Benjamin Herrenschmidt
2010-06-12 16:30 ` Mitch Bradley
2010-06-12 22:52 ` Benjamin Herrenschmidt
2010-06-13 5:07 ` Grant Likely
2010-06-13 5:39 ` Mitch Bradley
2010-06-13 5:59 ` Benjamin Herrenschmidt
2010-06-13 6:45 ` Mitch Bradley
2010-06-13 8:29 ` Benjamin Herrenschmidt
2010-06-14 5:36 ` Grant Likely
2010-06-14 20:00 ` Ben Dooks [this message]
2010-06-13 8:57 ` Benjamin Herrenschmidt
2010-06-14 5:23 ` Grant Likely
2010-06-14 7:38 ` Russell King - ARM Linux
2010-06-14 7:45 ` Mitch Bradley
2010-06-14 9:25 ` Russell King - ARM Linux
2010-06-14 9:36 ` Benjamin Herrenschmidt
2010-06-14 9:47 ` Russell King - ARM Linux
2010-06-14 14:29 ` Jamie Lokier
2010-06-14 13:51 ` Nicolas Pitre
2010-06-14 15:35 ` Grant Likely
2010-06-14 15:58 ` Nicolas Pitre
2010-06-14 16:16 ` Grant Likely
2010-06-14 5:02 ` Grant Likely
2010-06-14 12:44 ` David Gibson
2010-06-14 14:59 ` Nicolas Pitre
2010-06-14 15:08 ` Grant Likely
2010-06-14 16:02 ` Jamie Lokier
2010-06-14 16:23 ` Nicolas Pitre
2010-06-14 16:29 ` Grant Likely
2010-06-14 16:28 ` Grant Likely
2010-06-14 16:33 ` Jamie Lokier
2010-06-14 16:58 ` Mitch Bradley
2010-06-14 17:26 ` Nicolas Pitre
2010-06-14 18:20 ` Mitch Bradley
2010-06-14 19:40 ` Nicolas Pitre
2010-06-14 20:08 ` Mark Brown
2010-06-16 6:09 ` Mike Rapoport
2010-06-16 6:13 ` Mitch Bradley
2010-06-16 6:17 ` Mike Rapoport
2010-06-16 6:32 ` Mitch Bradley
2010-06-16 6:47 ` Mike Rapoport
2010-06-16 7:40 ` Mitch Bradley
2010-06-16 9:45 ` Vladimir Pantelic
2010-06-16 10:39 ` Mike Rapoport
2010-06-16 11:41 ` Jamie Lokier
2010-06-16 13:48 ` Jamie Bennett
2010-06-16 14:39 ` Nicolas Pitre
2010-06-16 17:43 ` Tim Bird
2010-06-16 6:52 ` M. Warner Losh
2010-06-18 22:12 ` Frank Rowand
2010-06-15 2:02 ` David Gibson
2010-06-14 15:51 ` M. Warner Losh
2010-06-13 5:48 ` Benjamin Herrenschmidt
2010-06-14 5:13 ` Grant Likely
2010-06-14 6:09 ` Benjamin Herrenschmidt
2010-06-14 6:17 ` Mitch Bradley
2010-06-12 22:15 ` Olof Johansson
2010-06-12 23:09 ` Grant Likely
2010-06-13 6:47 ` [microblaze-uclinux] " Edgar E. Iglesias
2010-06-12 3:00 ` Benjamin Herrenschmidt
2010-06-12 3:07 ` Benjamin Herrenschmidt
2010-06-13 13:12 ` Jeremy Kerr
2010-06-14 5:40 ` Grant Likely
2010-06-12 17:33 ` Stephan Gatzka
2010-06-12 18:19 ` Grant Likely
2010-06-14 5:54 ` Grant Likely
2010-08-05 4:43 ` David Gibson
2010-09-01 16:19 ` Grant Likely
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100614200000.GB7248@trinity.fluff.org \
--to=ben-linux@fluff.org \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=jeremy.kerr@canonical.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=microblaze-uclinux@itee.uq.edu.au \
--cc=nico@fluxnic.net \
--cc=olof@lixom.net \
--cc=ppc6dev@digitaldans.com \
--cc=wmb@firmworks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).