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]
Message-ID: <480C1286.3040307@firmworks.com>
Date:	Sun, 20 Apr 2008 18:05:26 -1000
From:	Mitch Bradley <wmb@...mworks.com>
To:	Yinghai Lu <yhlu.kernel@...il.com>
CC:	Andres Salomon <dilinger@...ued.net>,
	"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



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.

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.

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