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] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 28 May 2009 15:18:02 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Sascha Hauer <s.hauer@...gutronix.de>
cc:	Grant Likely <grant.likely@...retlab.ca>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Russell King <rmk+lkml@....linux.org.uk>,
	devicetree-discuss <devicetree-discuss@...abs.org>,
	linux-kernel@...r.kernel.org, Timur Tabi <timur@...escale.com>,
	Scott Wood <scottwood@...escale.com>,
	Janboe Ye <yuan-bo.ye@...orola.com>,
	linux-arm-kernel@...ts.arm.linux.org.uk
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform

On Thu, 28 May 2009, Sascha Hauer wrote:
> > There is the advantage of easy multiplatform support.  I regularly
> > build a single kernel image which boots on all my MPC5200 boards, and
> > on my MPC83xx boards.
> 
> That is not necessarily an advantage of a device tree. On ARM you can
> also build a kernel which runs on 20+ PXA platforms at the same time.
> (And I'm sure it can be done to even support say i.MX and PXA at the
> same time, but this is another story)

Well, you can run it on 20+ PXA platforms which have all their own
machine number, but you have all the little details of each platform
hardcoded into the kernel.

That does not help at all when your board has 5 variants just
different in subtle details which can not be probed or enumerated by
inspection. That's a common scenario in the embedded world.

So you either have 5 board numbers and all the details harcoded again
or you add some extra magic to deduce on which variant you are running
on.

We have seen almost everything in the weirdness range from poking in
some hardcoded FLASH cells over weird command line parsers up to a XML
parser which were added to work around the limitations of the machine
number model.

With a device tree you can avoid that crap and provide a standardized
interface for such cases.

I'm not saying that the device tree will make all those problems go
away magically, but it's orders of magnitudes better than what people
do now.

There is no need to force switch all of ARM to the device tree, but
adding support for it would be a good move. Nobody wants to enforce it
and both models can live happily side by side and we'll see which
variant turns out to be the long term favourite solution.

Thanks,

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ