linux-kernel - Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware

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:	Mon, 21 Apr 2008 10:24:17 -0400
From:	Andres Salomon <dilinger@...ued.net>
To:	Mitch Bradley <wmb@...mworks.com>
Cc:	Yinghai Lu <yhlu.kernel@...il.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Joseph Fannin <jfannin@...il.com>,
	linux-kernel@...r.kernel.org, jordan.crouse@....com
Subject: Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware

On Sun, 20 Apr 2008 18:05:26 -1000
Mitch Bradley <wmb@...mworks.com> wrote:

> 
> 
> Yinghai Lu wrote:
> > On Sun, Apr 20, 2008 at 8:09 PM, Mitch Bradley <wmb@...mworks.com> wrote:
> >   
> >>
> >>  Yinghai Lu wrote:
> >>
> >>     
> >>> how about changing to ofw_32.c?
> >>>
> >>> YH
> >>>
> >>>
> >>>       
> >>  Is your suggestion to change the filename from "ofw.c" to "ofw_32.c"?  That
> >> seems like a good idea to me.
> >>     
> >
> > Yes.
> >
> > BTW,  why olpc need OFW runtime service?
> > why not just put the info in in ram with some signiture, so
> > kernel/util just need to loot at the table if needed?
> >   
> 
> In SPARC land, at least on SunOS and Solaris, it was very convenient for 
> debugging to interrupt the OS with Stop-A and use OFW to inspect the 
> system state.  That was especially handy for live crash analysis.  Dumps 
> are useful as far as they go, but they often fail to capture detailed 
> I/O device state.
> 
> I was hoping to do that on x86 too.  So far we (OLPC) haven't 
> implemented a sysrq hook to enter OFW, but I haven't given up hope yet.  
> It doesn't cost much to leave OFW around, but once you decide to eject 
> it, you can't easily get it back.
> 

I'm not actually convinced that we *do* want to keep OFW resident in memory,
especially given the memory tricks we need to play.  I also don't actually
like the OFW interface that we.  The debugging aspect of it was a
compelling argument up until a week ago (when kernel debuggers started
finally finding their way into the kernel).

However, until we clean up the promfs stuff, there's no chance of getting
an OFW device tree upstream.


> Apple made the early decision to eject OFW and just keep a device tree 
> table.  That decision was probably due to several factors, including the 
> rather lame state of Apple's first OFW implementation and the complexity 
> of their OS startup process at the time (which included "trampolining" 
> to a 68000 emulator to run their legacy code).  Once they went down that 
> path, the die was cast, and the PowerPC community got used to the "OFW 
> ends up as just a table" idea.
> 
> >   


-- 
Need a kernel or Debian developer?  Contact me, I'm looking for contracts.
--
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/