Hi Simon
On Thu, Aug 25, 2011 at 9:41 AM, Simon Glass wrote:
> Hi Graeme,
[big snip]
>
> Ick. The more I read of this thread the more I like your original
> implementation. It really doesn't seem that hard to see the order of
> initcalls either from System.map or objdump | grep or similar. Writ
Hi Graeme,
On Wed, Aug 24, 2011 at 4:00 PM, Graeme Russ wrote:
> Hi Wolfgang
>
> On Wed, Aug 24, 2011 at 11:58 PM, Graeme Russ wrote:
>> Hi Wolfgang,
>>
>> On 24/08/11 23:24, Wolfgang Denk wrote:
>>> Dear Graeme Russ,
>>>
>>> In message <4e54f501.6050...@gmail.com> you wrote:
>
> [snip]
>
>>
>>
Hi Wolfgang
On Wed, Aug 24, 2011 at 11:58 PM, Graeme Russ wrote:
> Hi Wolfgang,
>
> On 24/08/11 23:24, Wolfgang Denk wrote:
>> Dear Graeme Russ,
>>
>> In message <4e54f501.6050...@gmail.com> you wrote:
[snip]
>
> Hmmm, now we're talking ;) Let me ramble aimlessly for a second...
>
> I can see t
Hi Wolfgang,
On 24/08/11 23:24, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <4e54f501.6050...@gmail.com> you wrote:
>>
>>> Sorry, but when reading the source code or when revioewing patches I
>>> cannot paick up any next funtion pointers, I'm stuck with reading the
>>> source code onl
Hi Wolfgang,
[...]
> I bet that rather sooner than later you will end up with some toold
> that parses either the ELF file or the linker map or the symbol table
> to generate a readable list for the current build. I bet a case of
> beer that you will need such a tool. We don't need it now.
obj
Dear Graeme Russ,
In message <4e54f501.6050...@gmail.com> you wrote:
>
> > Sorry, but when reading the source code or when revioewing patches I
> > cannot paick up any next funtion pointers, I'm stuck with reading the
> > source code only.
>
> Well, I guess I had a good shot at creating a 'bette
Hi Wolfgang,
On 24/08/11 22:49, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message
> you
> wrote:
>>
>>> Agreed. I should have written: I have a _readable_ source file that
>>> can be parsed without additional tools.
>>
>> I would hardly call 'grep' an extra tool - How many programmers d
Dear Graeme Russ,
In message
you wrote:
>
> > Agreed. I should have written: I have a _readable_ source file that
> > can be parsed without additional tools.
>
> I would hardly call 'grep' an extra tool - How many programmers do you
> know that have never used grep?
That's not the point. Th
Hi Wolfgang,
On Wed, Aug 24, 2011 at 4:48 PM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message
> you
> wrote:
>>
>> > But frankly: do you consider this list above _readable_?
> ...
>> grep is your friend - All you need to to is grep for GLOBAL (actually I
>> think COMMON is a better nam
Dear Graeme Russ,
In message
you wrote:
>
> > But frankly: do you consider this list above _readable_?
...
> grep is your friend - All you need to to is grep for GLOBAL (actually I
> think COMMON is a better name) and the ARCH, SOC, and BOARD keywords in
> the namespace for your board and voila
Hi Wolfgang,
On Wed, Aug 24, 2011 at 3:38 PM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message
> you
> wrote:
>>
>> So we end up with:
>>
>> #DEFINE INIT_GLOBAL_START 1
>> #DEFINE INIT_X86_CPU_FINIT_GLOBAL_START + 1
>> #DEFINE INIT_ARM_CPU_FINIT_G
Dear Graeme Russ,
In message
you wrote:
>
> So we end up with:
>
> #DEFINE INIT_GLOBAL_START 1
> #DEFINE INIT_X86_CPU_FINIT_GLOBAL_START + 1
> #DEFINE INIT_ARM_CPU_FINIT_GLOBAL_START + 1
> ...
> #DEFINE INIT_X86_INIT_X86_ + 1
> ...
> #DEF
Hi Wolfgang,
On Tue, Aug 23, 2011 at 9:49 PM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message
> you
> wrote:
>>
[snip]
>
>> > 2. One of the advantages of the current implementation is that there
>> > is a central place in the code (well, at least per architecture,
>> > untill we
Dear Mike Frysinger,
In message <201108222100.25104.vap...@gentoo.org> you wrote:
>
> >If you look at the current code - heavily larded with #ifdefs of
> >all shapes and colors - I cannot see any good way to transform this
> >into an initcall (and thus sequence number based) implementa
Dear Graeme Russ,
In message
you wrote:
>
> > 1. I think we should change the code in a different order. I would
> > prefer to first unify the init code across architectures (the big
> > ARM reorganization we just seem to have overcome was an important
> > prerequisite for this), before
Hi Mike
On Tue, Aug 23, 2011 at 11:00 AM, Mike Frysinger wrote:
> On Monday, August 22, 2011 16:10:23 Wolfgang Denk wrote:
>> 3. Hardware initialization in inherently very much hardware depen-
>>dent ;-) We have some boards where PCI must be initialized early
>>because it is needed to ac
On Monday, August 22, 2011 16:10:23 Wolfgang Denk wrote:
> 3. Hardware initialization in inherently very much hardware depen-
>dent ;-) We have some boards where PCI must be initialized early
>because it is needed to access some other peripherals like memory.
>And we have other boards
Hi Wolfgang,
On Tue, Aug 23, 2011 at 6:10 AM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <1313587343-3693-1-git-send-email-graeme.r...@gmail.com> you wrote:
>> I have been thinking about the problem of the pesky init_sequence arrays
>> and the inevitable #ifdefs and empty stub functi
Hi Wolfgang,
On Tue, Aug 23, 2011 at 6:10 AM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <1313587343-3693-1-git-send-email-graeme.r...@gmail.com> you wrote:
>> I have been thinking about the problem of the pesky init_sequence arrays
>> and the inevitable #ifdefs and empty stub functi
Dear Graeme Russ,
In message <1313587343-3693-1-git-send-email-graeme.r...@gmail.com> you wrote:
> I have been thinking about the problem of the pesky init_sequence arrays
> and the inevitable #ifdefs and empty stub functions that result so I
> thought I'de have a crack at a more dynamic implement
I have been thinking about the problem of the pesky init_sequence arrays
and the inevitable #ifdefs and empty stub functions that result so I
thought I'de have a crack at a more dynamic implementation. And like all
good programmers, I stole the solution ;). This implementation is based
on Linux's _
21 matches
Mail list logo
