Re: [PATCH] Open Firmware device tree virtual filesystem

From: Mitch Bradley <wmb@xxxxxxxxxxxxx>
Date: Sat, 30 Dec 2006 23:36:45 -1000

The base interface function is callofw(), which is effectively identical
to call_prom_ret() in arch/powerpc/kernel/prom_init.c . So it seems
that PowerPC could use it. I suppose I could change the name of
callofw() to call_prom_ret(), thus making the base interface identical
to PowerPC's. All it does is argument marshalling, translating between
C varargs argument lists and the OFW argarray format.

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

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.

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

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.

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.

But all of that really doesn't matter, if you use a functional
C interface for each device tree access operation, it doesn't
matter what's behind it right?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [PATCH] Open Firmware device tree virtual filesystem
    ... C varargs argument lists and the OFW argarray format. ... Except that none of the powerpc platforms can keep OF alive after the ... It is written to the standard OFW client interface. ... because ofw_fs only exports a read-only device tree and nothing else. ...
    (Linux-Kernel)
  • Re: [PATCH] Open Firmware device tree virtual filesystem
    ... 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 ... We didn't create a new interface here, ... the device tree to userland that isn't burdened by the powerpc ...
    (Linux-Kernel)
  • [RFC PATCH v2 05/12] PCI: beef up pci_do_scan_bus()
    ... We have a nice interface for re-scanning a PCI bus which will ... discover newly added devices, add them to the device tree, and ...
    (Linux-Kernel)
  • [PATCH v3 05/11] PCI: beef up pci_do_scan_bus()
    ... We have a nice interface for re-scanning a PCI bus which will ... discover newly added devices, add them to the device tree, and ...
    (Linux-Kernel)
  • Mel will travel the trap
    ... Don't even try to adapt a interface! ... amongst considerable councils, unless they're christian. ... She should nod distinct medals, ... Just locking no matter how a entrance outside the ...
    (sci.crypt)