Subject: Re: config & endianness
To: Quentin Garnier <firstname.lastname@example.org>
From: Garrett D'Amore <email@example.com>
Date: 03/06/2006 09:04:44
Quentin Garnier wrote:
> On Mon, Mar 06, 2006 at 08:46:03AM -0800, Garrett D'Amore wrote:
>> Quentin Garnier wrote:
>>> On Mon, Mar 06, 2006 at 08:27:36AM -0800, Garrett D'Amore wrote:
>>>> Hmm.... we now have some kernel configs in evbmips that do not make
>>>> sense for either big or little endian.
>>>> * OMSAL and MTX-1 are always little endian
>>>> * forthcoming ATHEROS AR531x based systems will always be big endian
>>>> * DBAU1XXX can be either endian (jumper selectable)
>>>> * Malta/PB1XXX? probably also jumper selectable
>>>> Is there a way to establish stuff in config so that:
>>>> 1) an attempt to build a kernel with endianness that doesn't make
>>>> sense fails in config(8), AND
>>> I don't really understand that. How is config(1) supposed to know what
>>> endianness it is supposed to build for? You want to flag it when it is
>>> compiled? Currently, config(1) is arch-agnostic, i.e. you can use the
>>> same binary for any arch.
>> I'm not talking about config(1) itself, rather I'm talking about having
>> the machinery in the kernel configuration files for this. So if you try
>> to build an evbmips-eb kernel using an MTX-1 config, it should fail.
>> Because this architecture (MTX-1) can *only* run little endian.
> But at which point do you know you're building an evbmips-eb kernel?
> If you want the information in the configuration files to conflict, it
> has to conflict with *something*.
> At the moment the user (or build.sh) does:
> $ config MYMIPSBOARD
> how is it supposed to know whether the rest of the toolchain uses the
> same endianness?
I don't know. I typically use build.sh, where you have to pass in the
arch with -m <arch> ala -m evbmips-el.
It can be that the failure mode could be stuffed into the Makefiles so
that make failed. make certainly needs to know which toolchain is being
used. I just picked on config because it seemed like that is where the
"option" for this belonged.
Probably I'm showing my ignorance of the config machinery here. :-)
The other half of the question is figuring out how to only build (&
release) kernels that make sense for a given endianness. I'd think
this would relieve some load on the nightly builds, and maybe reduce
confusion when some idiot tries to load a e.g. a big-endian kernel on
his little-endian-only machine.
Some users (e.g. Meshcube users, etc.) may not *know* what the
endianness of their system is, because it is a sealed in box and the
vendors don't supply this info. If we only supply kernels that make
sense, then they will be able to "figure it out".
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191