S A McConnell writes:
> head-armv.S, setup.c, proc-arm6,7.S:
> Why does the system use dynamic detection of processor id's and
> architectures? The code would be simpler and faster if configuration
> was used to specify those values. Making it no longer necessary to
> loop through these lists.
What's the point in making a lookup which only happens once fast? The
lists are needed to cope with kernels which can run on multiple
architectures. (eg, it is possible to compile one kernel for EBSA285,
CATS and NetWinder machines and have it work on all of these). Also,
some architectures may have different processors contained within.
(eg, RiscPC may be fitted with ARM6, ARM7 or StrongARM).
Without the dynamic detection, you'd probably end up with a total of
around 30 kernels only able to run on a specifically configured
machine.
> If the lists are still needed should the lists in head-armv.S and
> setup.c be collapsed into one list?
Yes and no. The processor and architecture lists must be independent.
I think you're thinking of the architecture lists more.
> head-armv.S:
> Uses magic numbers in __lookup_processor_type '#36' and in
> __lookup_architecture_type '16'. Should these be replaced with
> calculated constant definitions? Where should they be defined?
> (procinfo.h, ???)
The '16' is defined as the entry type of an assembly generated table
(contained within the same file and indeed within close proximity) -
there is absolutely no need to do anything different. Anyone modifing
the code should realise what this is doing.
The '36' is commented as a sizeof (struct). Since sizeof() is a C thing,
it doesn't work in assembler.
> The macro 'inituart' is defined but never referenced. Should it be
> moved to debug-armv.S?
I don't have this.
> setup.c:
> setup_processor() - The 'for loop' is repeating what was just done in
> __entry in head-armv.S. It appears to be impossible to make the "CPU
> configuration botched..." message be emitted.
Correct, but with one difference. The one in head-armv.S is running in
a different memory space, accessing the data via a physical address,
whereas the one in setup.c is using virtual addresses.
It is possible to use the assembler version and convert the address, so
this could be done.
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King [EMAIL PROTECTED] --- ---
| | | | http://www.arm.linux.org.uk/~rmk/armlinux.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
++ Please use [EMAIL PROTECTED] for ++
++ kernel-related discussions. ++
