1 |
On Wed, Jun 28, 2017 at 6:29 PM, James Le Cuirot <chewi@g.o> wrote: |
2 |
> On Wed, 28 Jun 2017 17:52:26 -0400 |
3 |
> Mike Gilbert <floppym@g.o> wrote: |
4 |
> |
5 |
>> On Tue, Jun 27, 2017 at 6:44 PM, James Le Cuirot <chewi@g.o> wrote: |
6 |
>> > I am therefore proposing a new global big-endian flag. This could be |
7 |
>> > masked by default and unmasked + forced in the relevant profiles under |
8 |
>> > arch. I will apply this according to the mapping defined in tc-endian of |
9 |
>> > toolchain-funcs.eclass. |
10 |
> |
11 |
> I've just been putting the patch together. I made it slightly simpler |
12 |
> by masking *and* forcing it by default so that it only needs to be |
13 |
> unmasked were necessary. |
14 |
> |
15 |
>> A possible alternative would be to create a new USE_EXPAND variable |
16 |
>> for this. That would allow for easier expansion in case we ever |
17 |
>> support something other than big/little endian machines. |
18 |
> |
19 |
> That way madness lies? Wikipedia talks about middle-endian as being the |
20 |
> catch all for other random orderings that have appeared over the years |
21 |
> but I don't think any of them were used on a system-wide basis. I can't |
22 |
> imagine Linux ever supporting such a thing. Unless you're talking about |
23 |
> dealing with soft vs hard float here too? |
24 |
|
25 |
No, I'm not referring to anything specifically. Just wanted to point |
26 |
out the possibility of having a multi-value variable instead of a |
27 |
boolean. |
28 |
|
29 |
If that seems very un-useful, please disregard. |