If the kernel can dynamically detect which processor and architecture it is
running on, then you don't need to build separate kernels for each. If you
only have one processor/architecture combination, then it doesn't matter,
but if you're supporting multiple it's much easier this way.
This code is small and only gets executed once at startup, so it doesn't
consume much time. There is a complexity issue with maintaining this code.
> If the lists are still needed should the lists in head-armv.S and
> setup.c be
> collapsed into one list?
I would vote in favor of this suggestion. I would like to see the
architecture data collected into a section, like the processor data is, with
each entry identified by the registered architecture number, rather than
position, so that the architecture data could be moved into the
architecture-specific files.
> 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, ???)
> (SAM)
Using a section for the procinfo and the architecture info would allow the
linker to calculate the currently manually maintained constants (#36 etc).
Accessing this data from assembly precludes the direct use of assembly
language, but we could store the necessary field offsets in variables that
are initialized via sizeof() and offsetof().
-Jamey
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
++ Please use [EMAIL PROTECTED] for ++
++ kernel-related discussions. ++
