Date: Wed, 03 Jan 2007 18:15:10 -0800 (PST)
Message-Id: <20070103.181510.00930133.davem@davemloft.net>
To: segher@kernel.crashing.org
Cc: linux-kernel@vger.kernel.org, devel@laptop.org, dmk@flex.com,
       benh@kernel.crashing.org, wmb@firmworks.com, jg@laptop.org
Subject: Re: [PATCH] Open Firmware device tree virtual filesystem
From: David Miller <davem@davemloft.net>
In-Reply-To: <1a41c67ddc85c317d358b32a274babdf@kernel.crashing.org>
References: <f07fd44aab26bf553ecdab5be5ee962e@kernel.crashing.org>
	<20070102.203417.102576086.davem@davemloft.net>
	<1a41c67ddc85c317d358b32a274babdf@kernel.crashing.org>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1405
Lines: 35

From: Segher Boessenkool <segher@kernel.crashing.org>
Date: Wed, 3 Jan 2007 16:23:53 +0100

> >>> therefore you can't let multiple CPUs call
> >>> into OFW at one time.  You must use some kind of locking mechanism,
> >>> and that locking mechanism is not simple because it has to not just
> >>> stop the other cpus, it has to be able to stop the other cpus yet
> >>> still allow them to receive SMP cross-calls from the firmware if the
> >>> OFW call is 'stop' or similar.
> >>
> >> YOu don't need to *stop* the other CPUs, you just need to
> >> prevent them from entering the client interface.  Put a lock
> >> in front.
> >
> > That's not the issue.
> >
> > If the global OFW lock disables interrupts,
> 
> Why would it?

Because if a serial/keyboard/other-console-input-device interrupt
arrives, from the user hitting the "BREAK" key sequence, you'll have
to enter OBP from a hardware interrupt handler.

Look, this thread is already tiring me, having to explain a lot
of things and not making much useful progress.  So I'll just be
honest and say that I'll go work on other things which need my
time and won't take part in this thread any more.

Take care.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/