On Thu, Jun 11, 2009 at 17:01, Konrad Eisele<konrad@xxxxxxxxxxx> wrote:
>>> enum mbus_module srmmu_modtype;
>>> @@ -568,6 +572,11 @@ static void srmmu_switch_mm(struct mm_st
>>> srmmu_ctxd_set(&srmmu_context_table[mm->context], mm->pgd);
>>> }
>>>
>>> +#ifdef CONFIG_SPARC_LEON
>>> + flush_tlb_mm(0);
>>> + if (leon_flush_during_switch)
>>> + leon_flush_cache_all();
>>> +#endif
>>> if (is_hypersparc)
>>> hyper_flush_whole_icache();
>>>
>>
>> Hmm... it would be nice to match the style of the statement after
>> this, something like:
>>
>> if (is_leon) {
>> flush_tlb_mm(0);
>> if (leon_flush_during_switch)
>> leon_flush_cache_all();
>> }
>>
>> But that would mean that the leon_flush_during_switch and
>> leon_flush_cache_all() would have to be defined for the non-SPARC_LEON
>> case, which isn't what you're trying to do here, however if
>> leon_flush_cache_all() is defined as a blank function, the compiler
>> *should* optimise all this away.
>>
>
> I'm not shure what to do here. I wonder weather
> if (is_leon) {
> is better than a
> #ifdef CONFIG_SPARC_LEON
> it seems to me that the later is better.
> It seems to me that in case of the former you have to have the
> implicit knowledge that the compiler will optimize away the
> function calls (and you have to search your way through the source
> code to come to a conclusion that it will), and this is quite more
> complex and disturbing than a #ifdef. I'd think #ifdef CONFIG_SPARC_LEON
> is much cleaner.
> Moreover it is not in line with the general strategy: to make leon-specific
> parts be only compiled in when CONFIG_SPARC_LEON is defined. Then all
> leon_mm.c
> and leon_kernel.c should also be compiled in always and protected with
> is_leon()
> instead of only compiling it in the CONFIG_SPARC_LEON case...
>
> But, hey, he, who checkes in, decides. Maybe Dave Miller can say how it
> should be.
I should possibly explain myself here a little.
My agenda with hacking on SparcLinux is to get 32-bit Sparc fully
tested and working with current kernel releases. (At the moment, I've
completed phase 1, getting the hardware and am slowly working on phase
2, getting it to boot.)
My methodology is to decrease the 32-bit specific parts of the code to
the absolute minimum, whilst removing ifdef guards where possible to
allow other methods, e.g. Kconfig, to choose which bits are compiled
or not, with the end goal being that there is little difference
between a 32-bit kernel and a 64-bit kernel.
As I cast my eye over all these changes for SPARC LEON, I'm looking at
the code in exactly the same way, asking myself the question "How can
we merge this code into the existing code leaving little special-case
code?"
I understand your goals with this - get LEON support upstream, don't
break existing systems - and I understand your methodology - making
your changes disappear when SPARC_LEON is unset - but I *know* that
I'll be submitting patches to do exactly what I'm talking about once
I'm hacking at this again.
Back to the code.
As for leon_kernel.c and leon_mm.c, they shouldn't be compiled unless
CONFIG_LEON is set, exactly as you have it now.
As for this code, the cleanest option I see is to make leon_init() and
leon_flush_cache_all() no-ops (or empty macros) when CONFIG_LEON isn't
set. My rationale for this is simple: support for HyperSPARC CPUs adds
some "dead" code on my MicroSPARC / SuperSPARC machines, and yet it
cannot be compiled out, so why should LEON CPUs be treated any
differently?
As for things like new hardware or new bus types, they add little
bulk, so I see no reason to cut them out when CONFIG_LEON isn't set. -
and for all we know, AMBA bus may become the emerging standard for
open source SPARC systems, not just LEON.
Thanks for understanding =)
--
Julian Calaby
Email: julian.calaby@xxxxxxxxx
.Plan: http://sites.google.com/site/juliancalaby/
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
