Re: config & endianness

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
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191