io_block_mapping in PPC64?

[Tzachi Perelstein]

Please forgive me, but although I absolutely accept your motivation, I
disagree with your conclusion. Linux ppc64 should have an alternative to
the 'desktop' device-tree structure, something that will be more
embedded systems friendly, like the compact U-Boot structure. It doesn't
mean that ppc64 arch will become a mess.
I will consult Wolfgang Denk, the U-Boot owner, about this matter. 
Regards,
Tzachi

> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh at kernel.crashing.org]
> Sent: Monday, May 16, 2005 11:07 AM
> To: Tzachi Perelstein
> Cc: linuxppc64-dev at ozlabs.org
> Subject: RE: io_block_mapping in PPC64?
> 
> On Mon, 2005-05-16 at 10:53 +0300, Tzachi Perelstein wrote:
> 
> > [Tzachi]: I do not use device-tree. Our Linux is loaded by U-Boot
which
> > first time supports the IBM-970FX and first time executed in 64-bit
> > mode. There is no real need for such complex structures when loaded
by
> > U-Boot. If you want ppc64 architecture to be spread to embedded
systems
> > too you should avoid such restrictions.
> 
> No, this will not happen. Look at ppc32. Every single board vendor
ended
> up hacking it's own board_info structure, which quickly became a total
> maintainance nightmare.
> 
> It is very easy and not complex at all to provide at least a simple
> device-tree to the kernel. What we might do to "help" here may be to
> provide some code for things like uboot to generate it based on a
simple
> ASCII definition or something like that. But there is simply no way I
> will let arbitrary structures be invented for every new board out
there
> and be passed around, turning the ppc64 kernel into the same kind of
> unmanageable mess that ppc32 is nowadays.
> 
> There are also open implementations of Open Firmware floating around
> (but I agree a solution that can be fitted in uboot would be useful).
> 
> I'm pretty confident that Paul Mackerras (ppc64 architecture
maintainer)
> agrees with me here.
> 
> Ben.
>