* Re: [PATCH 0/4] Speed up the symbols' resolution process V4
From: Alessio Igor Bogani @ 2011-05-11 13:44 UTC (permalink / raw)
To: Mike Frysinger
Cc: Rusty Russell, Tim Abbott, Anders Kaseorg, Jason Wessel, Tim Bird,
LKML, Linux Embedded
In-Reply-To: <BANLkTinDiGCaKPtS+ZpKf2swJpParJ4eew@mail.gmail.com>
Dear Mr. Frysinger,
2011/5/11 Alessio Igor Bogani <abogani@kernel.org>:
[...]
>>> this breaks symbol prefixed arches (like Blackfin):
>>> CC kernel/softirq.o
>>> /tmp/ccp3A6LU.s: Assembler messages:
>>> /tmp/ccp3A6LU.s:3734: Error: symbol `___ksymtab__local_bh_enable' is
>>> already defined
[...]
>>> name. so rather than "__", use "+".
>
> Sorry I don't think that is a good choice from a long term point of
> view. What do you think to add MODULE_SYMBOL_PREFIX to section names
> instead? In this way symbol and section names should always be
> different also on symbol prefixed archs (which are blackfin and
> h8300).
I'm thinking to something like this:
diff --git a/include/linux/module.h b/include/linux/module.h
index 98ddaf0..c4aa266 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -223,7 +223,7 @@ struct module_use {
extern void *__crc_##sym __attribute__((weak)); \
static const unsigned long __kcrctab_##sym \
__used \
- __attribute__((section("___kcrctab" sec "__"#sym), unused)) \
+ __attribute__((section("___kcrctab" sec "___" MODULE_SYMBOL_PREFIX
#sym), unused)) \
= (unsigned long) &__crc_##sym;
#else
#define __CRC_SYMBOL(sym, sec)
@@ -238,7 +238,7 @@ struct module_use {
= MODULE_SYMBOL_PREFIX #sym; \
static const struct kernel_symbol __ksymtab_##sym \
__used \
- __attribute__((section("___ksymtab" sec "__"#sym), unused)) \
+ __attribute__((section("___ksymtab" sec "___" MODULE_SYMBOL_PREFIX
#sym), unused)) \
= { (unsigned long)&sym, __kstrtab_##sym }
#define EXPORT_SYMBOL(sym) \
Could you try this, please?
Thank you very much!
Ciao,
Alessio
^ permalink raw reply related
* Re: [PATCH 0/4] Speed up the symbols' resolution process V4
From: Alessio Igor Bogani @ 2011-05-11 9:19 UTC (permalink / raw)
To: Mike Frysinger
Cc: Rusty Russell, Tim Abbott, Anders Kaseorg, Jason Wessel, Tim Bird,
LKML, Linux Embedded
In-Reply-To: <BANLkTimfFEv+vZ8dYvhG0oj2Q4g+KnG4aA@mail.gmail.com>
Dear Mr. Frysinger,
2011/5/11 Alessio Igor Bogani <abogani@kernel.org>:
> 2011/5/11 Mike Frysinger <vapier.adi@gmail.com>:
>> this breaks symbol prefixed arches (like Blackfin):
>> CC kernel/softirq.o
>> /tmp/ccp3A6LU.s: Assembler messages:
>> /tmp/ccp3A6LU.s:3734: Error: symbol `___ksymtab__local_bh_enable' is
>> already defined
>> make[1]: *** [kernel/softirq.o] Error 1
>
> Could you provide the preprocessed file and details about the toolchain used?
Please ignore this now I can reproduce the problem on my machine.
>> name. so rather than "__", use "+".
Sorry I don't think that is a good choice from a long term point of
view. What do you think to add MODULE_SYMBOL_PREFIX to section names
instead? In this way symbol and section names should always be
different also on symbol prefixed archs (which are blackfin and
h8300).
Thank you very much!
Ciao,
Alessio
^ permalink raw reply
* Re: [PATCH 0/4] Speed up the symbols' resolution process V4
From: Alessio Igor Bogani @ 2011-05-11 7:04 UTC (permalink / raw)
To: Mike Frysinger
Cc: Rusty Russell, Tim Abbott, Anders Kaseorg, Jason Wessel, Tim Bird,
LKML, Linux Embedded
In-Reply-To: <BANLkTi=y60Jt3-OMzbxQJzGkvzCzNJfJtA@mail.gmail.com>
Dear Mr. Frysinger,
2011/5/11 Mike Frysinger <vapier.adi@gmail.com>:
> this breaks symbol prefixed arches (like Blackfin):
> CC kernel/softirq.o
> /tmp/ccp3A6LU.s: Assembler messages:
> /tmp/ccp3A6LU.s:3734: Error: symbol `___ksymtab__local_bh_enable' is
> already defined
> make[1]: *** [kernel/softirq.o] Error 1
Could you provide the preprocessed file and details about the toolchain used?
Thanks!
Ciao,
Alessio
^ permalink raw reply
* Re: [PATCH 0/4] Speed up the symbols' resolution process V4
From: Mike Frysinger @ 2011-05-11 3:32 UTC (permalink / raw)
To: Alessio Igor Bogani
Cc: Rusty Russell, Tim Abbott, Anders Kaseorg, Jason Wessel, Tim Bird,
LKML, Linux Embedded
In-Reply-To: <1302960373-5309-1-git-send-email-abogani@kernel.org>
On Sat, Apr 16, 2011 at 09:26, Alessio Igor Bogani wrote:
> In the first place I changed the code for place every symbol in a different
> section (for example: "___ksymtab" sec "__" #sym) at compile time (this the
> above mentioned trick!). Thus I request to the linker to sort and merge all
> these sections into the appropriate ones (for example: "__ksymtab") at link
> time using the linker scripts. Once all symbols are sorted we can use binary
> search instead of the linear one.
this breaks symbol prefixed arches (like Blackfin):
CC kernel/softirq.o
/tmp/ccp3A6LU.s: Assembler messages:
/tmp/ccp3A6LU.s:3734: Error: symbol `___ksymtab__local_bh_enable' is
already defined
make[1]: *** [kernel/softirq.o] Error 1
this is because your new system of section naming happens to overlap
actual symbol names and the gnu assembler does not allow you to
declare a section and a symbol with the same name.
might be better to pick a separator that cannot appear in a symbol
name. so rather than "__", use "+". or some other funky char.
-mike
^ permalink raw reply
* Re: [RFC PATCH] arm: drop Execute-In-Place
From: Tony Lindgren @ 2011-05-06 6:07 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Russell King, linux-embedded, Mike Frysinger, David Woodhouse,
Nicolas Ferre, Tim Bird, Eric Miao,
Jean-Christophe PLAGNIOL-VILLARD,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <alpine.LFD.2.00.1105051518580.24613@xanadu.home>
* Nicolas Pitre <nicolas.pitre@linaro.org> [110505 22:23]:
> On Thu, 5 May 2011, Tim Bird wrote:
> >
> > I should add that I tried to use XIP on omap (for research purposes),
> > but it was broken and I didn't have time to fix it. My bad.
>
> OMAP is doing pretty nasty things with their early serial port support.
> This is most likely to screw up XIP.
Yes to debug it you'd have to hardcode the uart_phys and virt
in the debug-macro.S for DEBUG_LL and EARLY_PRINTK. But should
be easy enough to do for anybody using XIP.
Of course there may also be other issues too :)
Tony
^ permalink raw reply
* Re: [RFC PATCH] arm: drop Execute-In-Place
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-05-06 5:17 UTC (permalink / raw)
To: Mike Frysinger
Cc: Nicolas Pitre, Russell King, linux-embedded, Tony Lindgren,
Nicolas Ferre, Tim Bird, Eric Miao, David Woodhouse,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <BANLkTi=qiX9oG=ZMx0nZXrG811L7OZg4ww@mail.gmail.com>
On 16:31 Thu 05 May , Mike Frysinger wrote:
> On Thu, May 5, 2011 at 16:25, Tim Bird wrote:
> > On 05/05/2011 12:27 PM, Mike Frysinger wrote:
> >> On Thu, May 5, 2011 at 15:12, Tim Bird wrote:
> >>> As for in-tree-ness - I thought the most recent message was to stay
> >>> out of tree until the refactoring was over. ;-)
> >>
> >> to be fair, does this have any relevance whatsoever to NEC parts ?
> >> istm that the hindrance here is NEC doing any actual work for
> >> mainline. even if there was no refactoring, i find it hard to believe
> >> that an NEC port would be posted. if it were actually something that
> >> could happen, then they should already be posting patches for *basic*
> >> review to get the pieces unrelated to the refactoring worked out.
> >> there's no reason this has to be done serially.
> >
> > Well, OK. I just don't want to lob bombs at NEC and then
> > have some poor soul over there get immediately rebuffed, due to
> > basic ARM churn. Maybe not having naviengine support upstream
> > is my fault, but Sony doesn't make the CPU, so it doesn't seem
> > like it should be my job to mainline the chip support. About
> > the only thing I have at my disposal is pressure not to buy
> > the chip (but this is harder to exercise than one might think.)
>
> i dont have any vested interest either way wrt NEC or ARM/XIP. i was
> just trying to highlight what i saw as a red herring.
>
> i think the axiom "post early & post often" holds just as true here.
I've the same felling as Mike or David
Out of tree does not exist
Specially when they do effort to come mainline
Best Regards,
J.
^ permalink raw reply
* Re: [RFC PATCH] arm: drop Execute-In-Place
From: Mike Frysinger @ 2011-05-05 20:31 UTC (permalink / raw)
To: Tim Bird
Cc: Nicolas Pitre, David Woodhouse, Jean-Christophe PLAGNIOL-VILLARD,
Russell King, Tony Lindgren, Nicolas Ferre, Eric Miao,
linux-arm-kernel@lists.infradead.org, linux-embedded
In-Reply-To: <4DC307D0.3090704@am.sony.com>
On Thu, May 5, 2011 at 16:25, Tim Bird wrote:
> On 05/05/2011 12:27 PM, Mike Frysinger wrote:
>> On Thu, May 5, 2011 at 15:12, Tim Bird wrote:
>>> As for in-tree-ness - I thought the most recent message was to stay
>>> out of tree until the refactoring was over. ;-)
>>
>> to be fair, does this have any relevance whatsoever to NEC parts ?
>> istm that the hindrance here is NEC doing any actual work for
>> mainline. even if there was no refactoring, i find it hard to believe
>> that an NEC port would be posted. if it were actually something that
>> could happen, then they should already be posting patches for *basic*
>> review to get the pieces unrelated to the refactoring worked out.
>> there's no reason this has to be done serially.
>
> Well, OK. I just don't want to lob bombs at NEC and then
> have some poor soul over there get immediately rebuffed, due to
> basic ARM churn. Maybe not having naviengine support upstream
> is my fault, but Sony doesn't make the CPU, so it doesn't seem
> like it should be my job to mainline the chip support. About
> the only thing I have at my disposal is pressure not to buy
> the chip (but this is harder to exercise than one might think.)
i dont have any vested interest either way wrt NEC or ARM/XIP. i was
just trying to highlight what i saw as a red herring.
i think the axiom "post early & post often" holds just as true here.
-mike
^ permalink raw reply
* Re: [RFC PATCH] arm: drop Execute-In-Place
From: Tim Bird @ 2011-05-05 20:25 UTC (permalink / raw)
To: Mike Frysinger
Cc: Nicolas Pitre, Russell King, linux-embedded, Tony Lindgren,
David Woodhouse, Nicolas Ferre, Eric Miao,
Jean-Christophe PLAGNIOL-VILLARD,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <BANLkTincnFhwXAyvua5mtZDHqXs5Vts--Q@mail.gmail.com>
On 05/05/2011 12:27 PM, Mike Frysinger wrote:
> On Thu, May 5, 2011 at 15:12, Tim Bird wrote:
>> On 05/05/2011 12:04 PM, Mike Frysinger wrote:
>>> On Thu, May 5, 2011 at 14:54, Nicolas Pitre wrote:
>>>> On Thu, 5 May 2011, Tim Bird wrote:
>>>>> On 05/05/2011 11:32 AM, David Woodhouse wrote:
>>>>>> On Thu, 2011-05-05 at 11:03 -0700, Tim Bird wrote:
>>>>>>> On 05/05/2011 11:00 AM, Tim Bird wrote:
>>>>>>>> On 05/05/2011 07:52 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>>>>>> nearly no-one use it, only amop1, pxa and sa1100 implement it
>>>>>>>>
>>>>>>>> Sony uses this - a lot. Principally we're using this on a NEC
>>>>>>>> naviengine part, which is ARM11MPCore based, support for which
>>>>>>>> is (sadly) out of tree.
>>>>>>
>>>>>> If you're out of tree, you don't exist.
>>>>>
>>>>> Yeah - I know. I guess I should tell NEC we'll drop support
>>>>> for their chip and move to another one that supports XIP
>>>>> if they don't get their act together. If XIP survives...
>>>>
>>>> It is easy enough to keep it alive... as long as someone uses it of
>>>> course.
>>>
>>> i think David's point:
>>> ... someone <in tree> uses it ...
>>
>> I should add that I tried to use XIP on omap (for research purposes),
>> but it was broken and I didn't have time to fix it. My bad.
>> If anyone is using XIP on in-tree platforms, I'd like to hear
>> about it.
>
> XIP on Blackfin should work right now, but that doesnt directly apply
> to the patch in question here. it does however imply that other
> pieces in the stack work (like the MTD/mm layers).
>
>> As for in-tree-ness - I thought the most recent message was to stay
>> out of tree until the refactoring was over. ;-)
>
> to be fair, does this have any relevance whatsoever to NEC parts ?
> istm that the hindrance here is NEC doing any actual work for
> mainline. even if there was no refactoring, i find it hard to believe
> that an NEC port would be posted. if it were actually something that
> could happen, then they should already be posting patches for *basic*
> review to get the pieces unrelated to the refactoring worked out.
> there's no reason this has to be done serially.
Well, OK. I just don't want to lob bombs at NEC and then
have some poor soul over there get immediately rebuffed, due to
basic ARM churn. Maybe not having naviengine support upstream
is my fault, but Sony doesn't make the CPU, so it doesn't seem
like it should be my job to mainline the chip support. About
the only thing I have at my disposal is pressure not to buy
the chip (but this is harder to exercise than one might think.)
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================
^ permalink raw reply
* Re: [RFC PATCH] arm: drop Execute-In-Place
From: Vitaly Wool @ 2011-05-05 20:05 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Tim Bird, Russell King, linux-embedded, Mike Frysinger,
Tony Lindgren, David Woodhouse, Nicolas Ferre, Eric Miao,
Jean-Christophe PLAGNIOL-VILLARD,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <alpine.LFD.2.00.1105051518580.24613@xanadu.home>
On Thu, May 5, 2011 at 9:27 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> Just to be clear... We have XIP in the tree already. If it is useful
> to someone, in-tree or out-of-tree, then it is worth keeping around.
> Even if the only user was out-of-tree which certainly wasn't the case
> when I added XIP support to the kernel, then ripping it out and adding
> it back later would be more trouble than preserving it.
>
> What I was asking recently is whether or not XIP is still useful to
> someone today. Apparently it is, which is the answer I was looking for.
Surely it is. The last thing I tried was the i.mx deviation which is
very much based on what's in the tree. It didn't work out without some
bits of hackery and I never got it straight enough to try upstreaming.
But nevertheless, IMO XIP is not dead and is not going to be in the
closest future.
~Vitaly
^ permalink raw reply
* Re: [RFC PATCH] arm: drop Execute-In-Place
From: Mike Frysinger @ 2011-05-05 19:27 UTC (permalink / raw)
To: Tim Bird
Cc: Nicolas Pitre, David Woodhouse, Jean-Christophe PLAGNIOL-VILLARD,
Russell King, Tony Lindgren, Nicolas Ferre, Eric Miao,
linux-arm-kernel@lists.infradead.org, linux-embedded
In-Reply-To: <4DC2F6B0.80800@am.sony.com>
On Thu, May 5, 2011 at 15:12, Tim Bird wrote:
> On 05/05/2011 12:04 PM, Mike Frysinger wrote:
>> On Thu, May 5, 2011 at 14:54, Nicolas Pitre wrote:
>>> On Thu, 5 May 2011, Tim Bird wrote:
>>>> On 05/05/2011 11:32 AM, David Woodhouse wrote:
>>>>> On Thu, 2011-05-05 at 11:03 -0700, Tim Bird wrote:
>>>>>> On 05/05/2011 11:00 AM, Tim Bird wrote:
>>>>>>> On 05/05/2011 07:52 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>>>>> nearly no-one use it, only amop1, pxa and sa1100 implement it
>>>>>>>
>>>>>>> Sony uses this - a lot. Principally we're using this on a NEC
>>>>>>> naviengine part, which is ARM11MPCore based, support for which
>>>>>>> is (sadly) out of tree.
>>>>>
>>>>> If you're out of tree, you don't exist.
>>>>
>>>> Yeah - I know. I guess I should tell NEC we'll drop support
>>>> for their chip and move to another one that supports XIP
>>>> if they don't get their act together. If XIP survives...
>>>
>>> It is easy enough to keep it alive... as long as someone uses it of
>>> course.
>>
>> i think David's point:
>> ... someone <in tree> uses it ...
>
> I should add that I tried to use XIP on omap (for research purposes),
> but it was broken and I didn't have time to fix it. My bad.
> If anyone is using XIP on in-tree platforms, I'd like to hear
> about it.
XIP on Blackfin should work right now, but that doesnt directly apply
to the patch in question here. it does however imply that other
pieces in the stack work (like the MTD/mm layers).
> As for in-tree-ness - I thought the most recent message was to stay
> out of tree until the refactoring was over. ;-)
to be fair, does this have any relevance whatsoever to NEC parts ?
istm that the hindrance here is NEC doing any actual work for
mainline. even if there was no refactoring, i find it hard to believe
that an NEC port would be posted. if it were actually something that
could happen, then they should already be posting patches for *basic*
review to get the pieces unrelated to the refactoring worked out.
there's no reason this has to be done serially.
-mike
^ permalink raw reply
* Re: [RFC PATCH] arm: drop Execute-In-Place
From: Nicolas Pitre @ 2011-05-05 19:27 UTC (permalink / raw)
To: Tim Bird
Cc: Mike Frysinger, David Woodhouse, Jean-Christophe PLAGNIOL-VILLARD,
Russell King, Tony Lindgren, Nicolas Ferre, Eric Miao,
linux-arm-kernel@lists.infradead.org, linux-embedded
In-Reply-To: <4DC2F6B0.80800@am.sony.com>
On Thu, 5 May 2011, Tim Bird wrote:
> On 05/05/2011 12:04 PM, Mike Frysinger wrote:
> > On Thu, May 5, 2011 at 14:54, Nicolas Pitre wrote:
> >> On Thu, 5 May 2011, Tim Bird wrote:
> >>> On 05/05/2011 11:32 AM, David Woodhouse wrote:
> >>>> On Thu, 2011-05-05 at 11:03 -0700, Tim Bird wrote:
> >>>>> On 05/05/2011 11:00 AM, Tim Bird wrote:
> >>>>>> On 05/05/2011 07:52 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>>>>>> nearly no-one use it, only amop1, pxa and sa1100 implement it
> >>>>>>
> >>>>>> Sony uses this - a lot. Principally we're using this on a NEC
> >>>>>> naviengine part, which is ARM11MPCore based, support for which
> >>>>>> is (sadly) out of tree.
> >>>>
> >>>> If you're out of tree, you don't exist.
> >>>
> >>> Yeah - I know. I guess I should tell NEC we'll drop support
> >>> for their chip and move to another one that supports XIP
> >>> if they don't get their act together. If XIP survives...
> >>
> >> It is easy enough to keep it alive... as long as someone uses it of
> >> course.
> >
> > i think David's point:
> > ... someone <in tree> uses it ...
>
> I should add that I tried to use XIP on omap (for research purposes),
> but it was broken and I didn't have time to fix it. My bad.
OMAP is doing pretty nasty things with their early serial port support.
This is most likely to screw up XIP.
> If anyone is using XIP on in-tree platforms, I'd like to hear
> about it.
>
> As for in-tree-ness - I thought the most recent message was to stay
> out of tree until the refactoring was over. ;-)
Just to be clear... We have XIP in the tree already. If it is useful
to someone, in-tree or out-of-tree, then it is worth keeping around.
Even if the only user was out-of-tree which certainly wasn't the case
when I added XIP support to the kernel, then ripping it out and adding
it back later would be more trouble than preserving it.
What I was asking recently is whether or not XIP is still useful to
someone today. Apparently it is, which is the answer I was looking for.
Nicolas
^ permalink raw reply
* Re: [RFC PATCH] arm: drop Execute-In-Place
From: Tim Bird @ 2011-05-05 19:12 UTC (permalink / raw)
To: Mike Frysinger
Cc: Nicolas Pitre, David Woodhouse, Jean-Christophe PLAGNIOL-VILLARD,
Russell King, Tony Lindgren, Nicolas Ferre, Eric Miao,
linux-arm-kernel@lists.infradead.org, linux-embedded
In-Reply-To: <BANLkTimfKJPcDN+L4+z1DnsMv_BMOHpyew@mail.gmail.com>
On 05/05/2011 12:04 PM, Mike Frysinger wrote:
> On Thu, May 5, 2011 at 14:54, Nicolas Pitre wrote:
>> On Thu, 5 May 2011, Tim Bird wrote:
>>> On 05/05/2011 11:32 AM, David Woodhouse wrote:
>>>> On Thu, 2011-05-05 at 11:03 -0700, Tim Bird wrote:
>>>>> On 05/05/2011 11:00 AM, Tim Bird wrote:
>>>>>> On 05/05/2011 07:52 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>>>> nearly no-one use it, only amop1, pxa and sa1100 implement it
>>>>>>
>>>>>> Sony uses this - a lot. Principally we're using this on a NEC
>>>>>> naviengine part, which is ARM11MPCore based, support for which
>>>>>> is (sadly) out of tree.
>>>>
>>>> If you're out of tree, you don't exist.
>>>
>>> Yeah - I know. I guess I should tell NEC we'll drop support
>>> for their chip and move to another one that supports XIP
>>> if they don't get their act together. If XIP survives...
>>
>> It is easy enough to keep it alive... as long as someone uses it of
>> course.
>
> i think David's point:
> ... someone <in tree> uses it ...
I should add that I tried to use XIP on omap (for research purposes),
but it was broken and I didn't have time to fix it. My bad.
If anyone is using XIP on in-tree platforms, I'd like to hear
about it.
As for in-tree-ness - I thought the most recent message was to stay
out of tree until the refactoring was over. ;-)
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================
^ permalink raw reply
* Re: [RFC PATCH] arm: drop Execute-In-Place
From: Mike Frysinger @ 2011-05-05 19:04 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Tim Bird, David Woodhouse, Jean-Christophe PLAGNIOL-VILLARD,
Russell King, Tony Lindgren, Nicolas Ferre, Eric Miao,
linux-arm-kernel@lists.infradead.org, linux-embedded
In-Reply-To: <alpine.LFD.2.00.1105051453280.24613@xanadu.home>
On Thu, May 5, 2011 at 14:54, Nicolas Pitre wrote:
> On Thu, 5 May 2011, Tim Bird wrote:
>> On 05/05/2011 11:32 AM, David Woodhouse wrote:
>> > On Thu, 2011-05-05 at 11:03 -0700, Tim Bird wrote:
>> >> On 05/05/2011 11:00 AM, Tim Bird wrote:
>> >>> On 05/05/2011 07:52 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> >>>> nearly no-one use it, only amop1, pxa and sa1100 implement it
>> >>>
>> >>> Sony uses this - a lot. Principally we're using this on a NEC
>> >>> naviengine part, which is ARM11MPCore based, support for which
>> >>> is (sadly) out of tree.
>> >
>> > If you're out of tree, you don't exist.
>>
>> Yeah - I know. I guess I should tell NEC we'll drop support
>> for their chip and move to another one that supports XIP
>> if they don't get their act together. If XIP survives...
>
> It is easy enough to keep it alive... as long as someone uses it of
> course.
i think David's point:
... someone <in tree> uses it ...
-mike
^ permalink raw reply
* Re: [RFC PATCH] arm: drop Execute-In-Place
From: Nicolas Pitre @ 2011-05-05 18:54 UTC (permalink / raw)
To: Tim Bird
Cc: David Woodhouse, Jean-Christophe PLAGNIOL-VILLARD, Russell King,
Tony Lindgren, Nicolas Ferre, Eric Miao,
linux-arm-kernel@lists.infradead.org, linux-embedded
In-Reply-To: <4DC2EF19.5010309@am.sony.com>
On Thu, 5 May 2011, Tim Bird wrote:
> On 05/05/2011 11:32 AM, David Woodhouse wrote:
> > On Thu, 2011-05-05 at 11:03 -0700, Tim Bird wrote:
> >> On 05/05/2011 11:00 AM, Tim Bird wrote:
> >>> On 05/05/2011 07:52 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>>> nearly no-one use it, only amop1, pxa and sa1100 implement it
> >>>
> >>> Sony uses this - a lot. Principally we're using this on a NEC
> >>> naviengine part, which is ARM11MPCore based, support for which
> >>> is (sadly) out of tree.
> >
> > If you're out of tree, you don't exist.
>
> Yeah - I know. I guess I should tell NEC we'll drop support
> for their chip and move to another one that supports XIP
> if they don't get their act together. If XIP survives...
It is easy enough to keep it alive... as long as someone uses it of
course.
Nicolas
^ permalink raw reply
* Re: [RFC PATCH] arm: drop Execute-In-Place
From: Tim Bird @ 2011-05-05 18:40 UTC (permalink / raw)
To: David Woodhouse
Cc: Jean-Christophe PLAGNIOL-VILLARD, Nicolas Pitre, Russell King,
Tony Lindgren, Nicolas Ferre, Eric Miao,
linux-arm-kernel@lists.infradead.org, linux-embedded
In-Reply-To: <1304620350.2398.29.camel@i7.infradead.org>
On 05/05/2011 11:32 AM, David Woodhouse wrote:
> On Thu, 2011-05-05 at 11:03 -0700, Tim Bird wrote:
>> On 05/05/2011 11:00 AM, Tim Bird wrote:
>>> On 05/05/2011 07:52 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>> nearly no-one use it, only amop1, pxa and sa1100 implement it
>>>
>>> Sony uses this - a lot. Principally we're using this on a NEC
>>> naviengine part, which is ARM11MPCore based, support for which
>>> is (sadly) out of tree.
>
> If you're out of tree, you don't exist.
Yeah - I know. I guess I should tell NEC we'll drop support
for their chip and move to another one that supports XIP
if they don't get their act together. If XIP survives...
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================
^ permalink raw reply
* Re: [RFC PATCH] arm: drop Execute-In-Place
From: David Woodhouse @ 2011-05-05 18:32 UTC (permalink / raw)
To: Tim Bird
Cc: Jean-Christophe PLAGNIOL-VILLARD, Nicolas Pitre, Russell King,
Tony Lindgren, Nicolas Ferre, Eric Miao,
linux-arm-kernel@lists.infradead.org, linux-embedded
In-Reply-To: <4DC2E669.2000101@am.sony.com>
On Thu, 2011-05-05 at 11:03 -0700, Tim Bird wrote:
> On 05/05/2011 11:00 AM, Tim Bird wrote:
> > On 05/05/2011 07:52 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >> nearly no-one use it, only amop1, pxa and sa1100 implement it
> >
> > Sony uses this - a lot. Principally we're using this on a NEC
> > naviengine part, which is ARM11MPCore based, support for which
> > is (sadly) out of tree.
If you're out of tree, you don't exist.
--
dwmw2
^ permalink raw reply
* Re: [RFC PATCH] arm: drop Execute-In-Place
From: Tim Bird @ 2011-05-05 18:03 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Nicolas Pitre, Russell King, Tony Lindgren, Nicolas Ferre,
Eric Miao, linux-arm-kernel@lists.infradead.org, linux-embedded
In-Reply-To: <4DC2E5AA.5010604@am.sony.com>
On 05/05/2011 11:00 AM, Tim Bird wrote:
> On 05/05/2011 07:52 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> nearly no-one use it, only amop1, pxa and sa1100 implement it
>
> Sony uses this - a lot. Principally we're using this on a NEC
> naviengine part, which is ARM11MPCore based, support for which
> is (sadly) out of tree.
>
> I'd like to see MORE support for XIP in the kernel, not less.
>
> NAK from me.
By the way - it would be good to copy linux-embedded on this,
to expand the discussion.
I should have done that in my response, but I'm doing so now.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================
^ permalink raw reply
* Re: [PATCH] module: Use binary search in lookup_symbol()
From: Alessio Igor Bogani @ 2011-05-04 17:30 UTC (permalink / raw)
To: Dirk Behme
Cc: Rusty Russell, Tim Abbott, Anders Kaseorg, Tim Bird, LKML,
Linux Embedded, Jason Wessel
In-Reply-To: <4DC171EB.6030900@googlemail.com>
Dear Mr. Behme,
2011/5/4 Dirk Behme <dirk.behme@googlemail.com>:
[...]
> How is this patch related to patch 4/4
>
> http://marc.info/?l=linux-kernel&m=130296062420328&w=1
>
> of the recently sent patch set? Is it a replacement? Or an add on to this
> (i.e. patch #5)?
Sorry it's my fault: This patch is an add on to that patch set.
Ciao,
Alessio
^ permalink raw reply
* Re: [PATCH] module: Use binary search in lookup_symbol()
From: Dirk Behme @ 2011-05-04 15:34 UTC (permalink / raw)
To: Alessio Igor Bogani
Cc: Rusty Russell, Tim Abbott, Anders Kaseorg, Tim Bird, LKML,
Linux Embedded, Jason Wessel
In-Reply-To: <1304455330-2728-1-git-send-email-abogani@kernel.org>
On 03.05.2011 22:42, Alessio Igor Bogani wrote:
> This work was supported by a hardware donation from the CE Linux Forum.
>
> Signed-off-by: Alessio Igor Bogani<abogani@kernel.org>
> ---
> kernel/module.c | 6 ++----
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/module.c b/kernel/module.c
> index 6a34337..a1f841e 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -2055,10 +2055,8 @@ static const struct kernel_symbol *lookup_symbol(const char *name,
> const struct kernel_symbol *stop)
> {
> const struct kernel_symbol *ks = start;
> - for (; ks< stop; ks++)
> - if (strcmp(ks->name, name) == 0)
> - return ks;
> - return NULL;
> + return bsearch(ks->name, start, stop - start,
> + sizeof(struct kernel_symbol), cmp_name);
> }
>
> static int is_exported(const char *name, unsigned long value,
How is this patch related to patch 4/4
http://marc.info/?l=linux-kernel&m=130296062420328&w=1
of the recently sent patch set? Is it a replacement? Or an add on to
this (i.e. patch #5)?
Many thanks
Dirk
^ permalink raw reply
* [PATCH] module: Use binary search in lookup_symbol()
From: Alessio Igor Bogani @ 2011-05-03 20:42 UTC (permalink / raw)
To: Rusty Russell
Cc: Tim Abbott, Anders Kaseorg, Tim Bird, LKML, Linux Embedded,
Jason Wessel, Alessio Igor Bogani
This work was supported by a hardware donation from the CE Linux Forum.
Signed-off-by: Alessio Igor Bogani <abogani@kernel.org>
---
kernel/module.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/kernel/module.c b/kernel/module.c
index 6a34337..a1f841e 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2055,10 +2055,8 @@ static const struct kernel_symbol *lookup_symbol(const char *name,
const struct kernel_symbol *stop)
{
const struct kernel_symbol *ks = start;
- for (; ks < stop; ks++)
- if (strcmp(ks->name, name) == 0)
- return ks;
- return NULL;
+ return bsearch(ks->name, start, stop - start,
+ sizeof(struct kernel_symbol), cmp_name);
}
static int is_exported(const char *name, unsigned long value,
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 0/4] Speed up the symbols' resolution process V4
From: Dirk Behme @ 2011-04-27 15:31 UTC (permalink / raw)
To: Alessio Igor Bogani
Cc: Rusty Russell, Tim Abbott, Anders Kaseorg, Jason Wessel, Tim Bird,
LKML, Linux Embedded
In-Reply-To: <1302960373-5309-1-git-send-email-abogani@kernel.org>
On 16.04.2011 15:26, Alessio Igor Bogani wrote:
> The intent of this patch is to speed up the symbols resolution process.
>
> This objective is achieved by sorting all ksymtab* and kcrctab* symbols
> (those which reside both in the kernel and in the modules) and thus use the
> fast binary search.
>
> To avoid adding lots of code for symbols sorting I rely on the linker which can
> easily do the job thanks to a little trick. The trick isn't really beautiful to
> see but permits minimal changes to the code and build process. Indeed the patch
> is very simple and short.
>
> In the first place I changed the code for place every symbol in a different
> section (for example: "___ksymtab" sec "__" #sym) at compile time (this the
> above mentioned trick!). Thus I request to the linker to sort and merge all
> these sections into the appropriate ones (for example: "__ksymtab") at link
> time using the linker scripts. Once all symbols are sorted we can use binary
> search instead of the linear one.
>
> I'm fairly sure that this is a good speed improvement even though I haven't
> made any comprehensive benchmarking (but follow a simple one). In any case
> I would be very happy to receive suggestions about how made it. Collaterally,
> the boot time should be reduced also (proportionally to the number of modules
> and symbols nvolved at boot stage).
>
> I hope that you find that interesting!
>
> This work was supported by a hardware donation from the CE Linux Forum.
>
> Thanks to Ian Lance Taylor for help about how the linker works.
>
>
> Changes since V3:
> *) Please ignore this version completely
>
> Changes since V2:
> *) Fix a bug in each_symbol() semantics by Anders Kaseorg
> *) Split the work in three patches as requested by Rusty Russell
> *) Add a generic binary search implementation made by Tim Abbott
> *) Remove CONFIG_SYMBOLS_BSEARCH kernel option
>
> Changes since V1:
> *) Merge all patches into only one
> *) Remove few useless things
> *) Introduce CONFIG_SYMBOLS_BSEARCH kernel option
>
>
> Alessio Igor Bogani (3):
> module: Restructure each_symbol() code
> module: Sort exported symbols
> module: Use the binary search for symbols resolution
>
> Tim Abbott (1):
> lib: Add generic binary search function to the kernel.
>
> include/asm-generic/vmlinux.lds.h | 20 ++++----
> include/linux/bsearch.h | 9 ++++
> include/linux/module.h | 4 +-
> kernel/module.c | 84 ++++++++++++++++++++++++++++---------
> lib/Makefile | 3 +-
> lib/bsearch.c | 53 +++++++++++++++++++++++
> scripts/module-common.lds | 11 +++++
> 7 files changed, 151 insertions(+), 33 deletions(-)
> create mode 100644 include/linux/bsearch.h
> create mode 100644 lib/bsearch.c
Tested-by: Dirk Behme <dirk.behme@googlemail.com>
On an embedded ARM system insmoding a large number of modules the
overall module load time is improved up to ~1s. Great! :)
It would be nice to get these patches into mainline asap.
Many thanks
Dirk
^ permalink raw reply
* Re: Expose regulator:set_consumer_device_supply()?
From: Bill Gatliff @ 2011-04-26 21:15 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-embedded, linux-kernel
In-Reply-To: <20110426161516.GC11848@opensource.wolfsonmicro.com>
Mark:
On Tue, Apr 26, 2011 at 11:15 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
>
> No. As I said in the text you've quoted above you can also specify the
> device mapping using the dev_name() of the device.
Aah! I see it now--- the regulator_consumer_supply structure will
take either the consumer's struct device pointer, or the device name
of the consumer's struct device. The device name can easily be
predicted (controlled, in fact) before the consumer itself is
registered; in the case of i2c devices, it's the bus-id, i.e.
"0-0038".
Now it all fits together for me. Thanks for your patience!
> It means you get reams of code in drivers conditionally using the
> regulator API, all of which adds needless complexity all over the tree
> as people invariably make everything conditional on the regulator not
> being there when they shouldn't. This then means you also end up with
> no meaningful error handling, all errors just get silently eaten.
Now I think I see your point: better to have drivers check the result
of regulator_get() themselves, rather than test a pointer coming in
with the platform data. And since regulators are often registered as
platform devices themselves, there is no way to get a valid result
from regulator_get() in early-init board code anyway.
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: Expose regulator:set_consumer_device_supply()?
From: Mark Brown @ 2011-04-26 16:15 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linux-embedded, linux-kernel
In-Reply-To: <BANLkTimmpx5ZThXj705Yn_wRQ6bF7VzwPw@mail.gmail.com>
On Tue, Apr 26, 2011 at 10:33:29AM -0500, Bill Gatliff wrote:
> On Tue, Apr 26, 2011 at 3:33 AM, Mark Brown
> <broonie@opensource.wolfsonmicro.com> wrote:
> > You can specify the device by either dev_name() or a dev pointer. You
> > can use dev_name() at any time without the device having been
> > instantiated, it would be unusal to use a struct device.
> When a consumer e.g. i2c chip driver is trying to get a handle for its
> own regulator, the only function I see is:
>
> struct regulator* regulator_get(struct device *dev, const char *id)
There's also regulator_get_exclusive() but it's almost exactly the same
thing.
> In order for there to be a regulator with a matching device:id
> combination, someone must have previously provided a struct
> regulator_consumer_supply with the identical device pointer to
> regulator_register(). That means that I have to call
> regulator_register() AFTER I register the i2c chip driver, so that I
> have a struct device pointer to place in the regulator_consumer_supply
> list. Right?
No. As I said in the text you've quoted above you can also specify the
device mapping using the dev_name() of the device. As you will have
seen when looking through the regulator_get() implementation the
matching is actually done on the dev_name(), if the mapping is set up
with a struct device we always do matches based on the dev_name()
string, not by comparing pointers.
> > This would facilitate abuse of the API, we already have enough problems
> > with people trying to pass regulators as platform data.
> But I think you'll agree that regulators are pretty important platform data, no?
No, the set of power supplies the device has is not platform data, it's
a physical property of the device.
> What specifically is the breakage that comes from allowing consumers
> to add themselves to regulator consumer lists at a time after
> regulator_register() is complete? Why is passing a regulator pointer
> as platform data such a problem?
It means you get reams of code in drivers conditionally using the
regulator API, all of which adds needless complexity all over the tree
as people invariably make everything conditional on the regulator not
being there when they shouldn't. This then means you also end up with
no meaningful error handling, all errors just get silently eaten.
^ permalink raw reply
* Re: Expose regulator:set_consumer_device_supply()?
From: Bill Gatliff @ 2011-04-26 15:33 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-embedded, linux-kernel
In-Reply-To: <20110426083350.GA20595@sirena.org.uk>
Mark:
Thanks for the response. But now I'm even more confused than I was before!
On Tue, Apr 26, 2011 at 3:33 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> You can specify the device by either dev_name() or a dev pointer. You
> can use dev_name() at any time without the device having been
> instantiated, it would be unusal to use a struct device.
When a consumer e.g. i2c chip driver is trying to get a handle for its
own regulator, the only function I see is:
struct regulator* regulator_get(struct device *dev, const char *id)
My understanding, even after looking at the implementation of
regulator_get(), is that the dev pointer refers to the device
structure of the consumer itself. The regulator returned is one that
matches the combination of that device structure pointer plus the name
of the regulator. In other words, I get back the regulator that is
unambiguously associated with the consumer.
In order for there to be a regulator with a matching device:id
combination, someone must have previously provided a struct
regulator_consumer_supply with the identical device pointer to
regulator_register(). That means that I have to call
regulator_register() AFTER I register the i2c chip driver, so that I
have a struct device pointer to place in the regulator_consumer_supply
list. Right?
The alternative is to not indicate any regulator_consumer_supply
devices when I register a regulator, and then do the regulator_get()
by matching on name alone. But then I have to pass the regulator name
as platform data to the i2c chip driver, because that regulator's name
is bound to change across boards. And I also lose the strong
relationship between regulators and their downstream devices that
regulator_consumer_supply offers. If I can keep that association,
then consumers need only ask for "the regulator tied to my VCC pin,
whatever regulator that is".
Maybe I'm misunderstanding the utility of the dev pointer in regulator_get()?
>> Any reason why we couldn't expose set_consumer_device_supply(), so
>> that I can add a device as a regulator consumer after a regulator is
>> already registered?
>
> This would facilitate abuse of the API, we already have enough problems
> with people trying to pass regulators as platform data.
But I think you'll agree that regulators are pretty important platform data, no?
What specifically is the breakage that comes from allowing consumers
to add themselves to regulator consumer lists at a time after
regulator_register() is complete? Why is passing a regulator pointer
as platform data such a problem?
Confused,
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: Expose regulator:set_consumer_device_supply()?
From: Mark Brown @ 2011-04-26 8:34 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linux-embedded, lrg, linux-kerne
In-Reply-To: <BANLkTikQSus=o3=TVdEPBfnP6HZJvxt4Vw@mail.gmail.com>
On Mon, Apr 25, 2011 at 09:25:22PM -0500, Bill Gatliff wrote:
> This would also imply the ability to register a regulator with no
> consumers listed, as they would be added later when i2c, etc. devices
> were registered.
This is already possible, not all consumers are visible to software
anyway.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox