Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 18 Oct 2009 13:36:25 +0200
From:      Guillaume Ballet <gballet@gmail.com>
To:        Mark Tinguely <tinguely@casselton.net>
Cc:        freebsd-arm@freebsd.org, stas@deglitch.com
Subject:   Re: Adding members to struct cpu_functions
Message-ID:  <fd183dc60910180436k670648b0wca3900b8f47be6aa@mail.gmail.com>
In-Reply-To: <200910122129.n9CLTHsp087996@casselton.net>
References:  <fd183dc60910121335l13403214yb1642102e4c36e08@mail.gmail.com> <200910122129.n9CLTHsp087996@casselton.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 12, 2009 at 11:29 PM, Mark Tinguely <tinguely@casselton.net> wr=
ote:
>
>> =A0As a result, extending the struct cpu_functions is not a good thing
>> =A0either, for the same reason. The compiler can not inline a call
>> =A0through a function pointer.
>>
>> =A0In which case, why not create a bunch of headers files with the
>> =A0pattern cpufunc_myarch.h, in which all functions would be declared
>> =A0inline? Something like:
>>
>> =A0static inline l2_l_entry(vm_addr_t pa, int prot, int cache);
>> =A0static inline l2_s_entry(vm_addr_t pa, int prot, int cache);
>> =A0...
>> =A0which would then be included by pmap.c and friends.
>
> I think they need to be regular function calls because assembly routines
> call the per-cpu functions. A few simple macros would save the branch to =
NOP
> functions.
>

I'm not sure what you mean by that: would macros be ok, in your
opinion? I am a bit puzzled because I see a contradiction with the
previous sentence that requires the functions to be callable from the
assembly code. Obviously I am misinterpreting, so would you mind
clarifying, please?

I think it is important to notice that even though cache management
relies a lot on assembly function, I haven't found any page table
management done in assembly past locore.S. I think using macros for
page table management functions can be done. For cache management,
however, I agree that having different pmap.c files is probably the
way to go. In both cases, I am still curious to see what Nathan will
come up with.

I took a more thorough look at pmap, and there is indeed lots of
machine-specific code, especially at the beginning. And when it comes
to cpufunc, it's all about #ifdefs. Since I'm still working on the
cleanup for the beagleboard, I will declare cpufuncs in an
armv6-specific file. Let's call it cpufunc_armv6.c. I am struggling
with another MMU problem at the moment, but I'll try to come up asap
with a patch for pmap.c. It will replace hardcoded values with
machine-defined macros, for reference.

Guillaume



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fd183dc60910180436k670648b0wca3900b8f47be6aa>