<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 20.06.2009 2:46 Uhr, Carl-Daniel Hailfinger wrote:<br>
<blockquote cite="mid:4A3C317F.40703@gmx.net" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">A quick test abuild with #error inserted in the lockless function shows
we indeed use it for every freaking x86 target.
That explains the supermicro/h8dme intertwined printk messages Ward is
seeing.
</pre>
</blockquote>
<pre wrap="">They're from ram init stage afaict ...
</pre>
</blockquote>
<pre wrap=""><!---->
If we need them instead of the generic variants, we should know a reason
for such usage.
</pre>
</blockquote>
<br>
Yes, the reasons are<br>
<br>
- no console "drivers" in the stage2/coreboot_ram style at this level<br>
- no spinlocking because we have no ram that is available to and shared
by all cpus<br>
<br>
<blockquote cite="mid:4A3C317F.40703@gmx.net" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Besides that, do we know where static spinlock_t console_lock is placed?
</pre>
</blockquote>
<pre wrap="">In RAM
</pre>
</blockquote>
<pre wrap=""><!---->
So we'd get uninitialied data for any pre-RAM spinlock access? The v3
global variable mechanism should solve this nicely. At least it was
designed for that.</pre>
</blockquote>
But was it designed for safe IPC (Inter Processor Communication ;-) ?<br>
<br>
Stefan<br>
<br>
<br>
<pre class="moz-signature" cols="72">--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: <a class="moz-txt-link-abbreviated" href="mailto:info@coresystems.de">info@coresystems.de</a> • <a class="moz-txt-link-freetext" href="http://www.coresystems.de/">http://www.coresystems.de/</a>
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
</pre>
</body>
</html>