Message-ID: <45978CE9.7090700@flex.com>
Date:	Sun, 31 Dec 2006 02:11:53 -0800
From:	David Kahn <dmk@...x.com>
To:	David Miller <davem@...emloft.net>
CC:	Mitch Bradley <wmb@...mworks.com>, devel@...top.org,
	linux-kernel@...r.kernel.org, jg@...top.org
Subject: Re: [PATCH] Open Firmware device tree virtual filesystem


Responding to two replies in one email ...


Mitch Bradley wrote:
> 
> David Miller wrote:
>> ...
>> Can we please not have N different interfaces to the open-firmware
>> calls so that perhaps powerpc and Sparc have a chance of using this
>> code too?

David,

I helped Mitch do this "port", so I'd like to chime in here.

Mitch and I both looked extensively at the powerpc and sparc
code that's there. There's an entire extra layer there that
isn't needed if all you want to do is expose the device
tree to userland via the file system, and that's all that was
needed in this case, plus, the desire is to keep OFW in memory
in this case, so caching of the device tree is unnecessary for
this simple implementation.

We didn't create a new interface here, all we did was
write code for the existing OFW client interface and call it
directly, rather than go through extra layers of code to do
that.Both the existing powerpc and sparc code seems to be
burdened with the use of legacy interfaces.



David Miller wrote:

> Please create explicit function calls for each operation, this
> way the caller is immune to open-firmware implementation details.

I did that initially, but Mitch and I agreed that it's just
a waste of more code for this case, where the majority of
i386 implementations are not going to use it.

The opportunity for layering an interface in between the kernel
and the firmware still exists with the trivial callofw interface.

> 
>> SPARC should be able to use that same base interface function directly.  
>> It is written to the standard OFW client interface.
> 
> Sparc 32-bit predates the OFW specification and does things differently.

15 year old 32-bit SPARC machines use a different interface.
None of those machines are even supported by Sun anymore
(hardware or software support in any form.) Nonetheless,
we haven't changed any of that.

And by the way, Mitch and I are intimately familiar with that
stuff from our days together at Sun. (I'm still at Sun.) Mitch
and I have worked together on these firmware interfaces for a long
time now.

> 
> Please use a functional interface using a C function for each device
> tree operation, then the implementation behind it doesn't matter.

The opportunity for layering a different interface in between the kernel
and the firmware already exists with the callofw and cif_handler interfaces.
In fact, before Mitch got the code working, I had written an entire
emulation layer to test the file system code out. All it did was hook
into that existing cif_handler interface, providing its own address
rather than using a cif handler address in the firmware. At the end of
the day, Mitch got the cif calls working to the actual firmware before
we tried the emulation layer, but the point is that it was fairly trivial
to implement.

>> It wouldn't work on ancient Sun machines with the sunmon romvec 
>> interface, but Sun stopped making such machines something like 16 years ago.
> 
> Yet we still support them in the 32-bit sparc port.  And it's so
> easy to support this properly, please use the clean stuff we've
> created for this.

We haven't changed the sparc implementation, it all still works.
All we've done is created a trivial implementation for exporting
the device tree to userland that isn't burdened by the powerpc
and sparc legacy code that's in there now.

> 
>> I did consider first creating a memory data structure identical to the 
>> powerpc/sparc one, but that looked like it was going to be essentially 
>> twice as much code for no extra capability.  The code to traverse the 
>> device tree and create the memory data structure is roughly the same as 
>> the code to create the filesystem structure.  I just didn't see the 
>> value of an intermediate representation for systems that don't otherwise 
>> need it.
> 
> Since we put it in memory, we have zero reason to call into the
> firmware for device tree access and this simplifies things a lot.

And it also wastes resources, if all you need is a read-only
view of the device tree in the filesystem.

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