Thread (15 messages) 15 messages, 4 authors, 2010-09-28
STALE5750d

[PATCH] [ARM] Introduce patching of phys_to_virt and vice versa

From: nico@fluxnic.net (Nicolas Pitre)
Date: 2010-08-09 16:55:17

On Sun, 8 Aug 2010, Russell King - ARM Linux wrote:
On Fri, Aug 06, 2010 at 01:07:46PM -0400, Nicolas Pitre wrote:
quoted
No idea.  That depends how gcc is considering inline asm.  Given there 
is one input operand, I suppose gcc would account for the delay slot 
before that operand is actually available.
For something which could very well become by default enabled across
the board - due to the push to have a single kernel binary for lots
of significantly different platforms - it seems little research has
been carried out on this point.

While I agree that other obvious solutions would be more expensive, I
think it makes sense to have the commit which is introducing this
method include a proper evaluation, not least so that people who need
to make the decision to enable this aren't repeating the same research
that someone else has done (or, worse, just decide to enable it 'just
because' without any understanding of what the effect may be.)
Sure, I agree.  I'll contact gcc people for a definitive answer.
I think we also need to consider whether the volatile is really required.
This asm() doesn't have any side effects other than its output operand,
so I suspect that the volatile may get in the way of some optimisations
(such as deleting the operation if the output is not actually used.)
Indeed, the volatile should go.  This is even getting in the way of 
better scheduling.


Nicolas
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help