Jamey Hicks writes:
> 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.
"vote"? I wasn't aware that we had a general election today! ;)
There's one problem here - there aren't really any suitable per-architecture
files to move it into, and I'm dead against creating some just to store
this information.
The original idea behind the two lists was to (eventually) provide some way
of telling the user that they were running an incompatable kernel for their
architecture, but the code didn't materialise ;(
> 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().
That's, erm, even more disgusting than the arch/arm/lib/constants.h hack,
and will preclude the use of nicities like 'ldm'!
_____
|_____| ------------------------------------------------- ---+---+-
| | 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. ++
