1 |
On 09/21/2014 21:11, Anthony G. Basile wrote: |
2 |
> On 09/21/14 18:53, Joshua Kinard wrote: |
3 |
>> On 09/21/2014 17:55, Anthony G. Basile wrote: |
4 |
>>> On 09/17/14 16:19, Anthony G. Basile wrote: |
5 |
>> [snip] |
6 |
>>> |
7 |
>>> This isn't going to work. The problem is that the above structure doesn't |
8 |
>>> distinguish between mips/o32 and mips64/o32 (and equivalent el versions). Now |
9 |
>>> mips64/o32 is funny, but possible: it would be o32 (a 32-bit abi) on 64 bit |
10 |
>>> arch/kernel, like ppc64-32ul. The structure is possible at the level of |
11 |
>>> profile/arch, but it would mean a deep restructuring of |
12 |
>>> default/linux/mips/13.0. |
13 |
>> |
14 |
>> Err, I've been using this setup for the last 9+ years? My Octane and O2 both |
15 |
>> boot mips64 kernels and run an o32-only userland. It works fine with the |
16 |
>> current profile setup. You just use a mips-unknown-linux-gnu CHOST. I may not |
17 |
>> be able to fully utilize all of the CPU registers like I would under n32, but |
18 |
>> that's never been an issue for me. |
19 |
>> |
20 |
>> So there should be no need to differentiate at the userland level between |
21 |
>> mips/o32 and mips64/o32. As long as the CHOST is set correctly, o32 will work |
22 |
>> fine under a mips64 kernel (caveat: make sure CONFIG_MIPS32_O32 is set in the |
23 |
>> kernel). |
24 |
> |
25 |
> I agree that there shouldn't be any userland difference, but I'm not 100% |
26 |
> sure. Anyhow, let's go with that assumption for now. |
27 |
|
28 |
There isn't. If there is a difference that can be detected (meaning, with a |
29 |
machine that can run in 32-bit or 64-bit mode with the same userland), then |
30 |
you're looking at a kernel problem and that would get handled via upstream |
31 |
channels. You're actually at a big disadvantage running o32 under a 64-bit |
32 |
kernel, because of not being able to use all of the registers in the CPU, can |
33 |
only pass the first four function args via registers (8 in n32), etc. o32 is |
34 |
for all intents and purposes, the MIPS-I and MIPS-II ISAs, which are core to |
35 |
the overall ISA set, and so all MIPS CPUs to date should (in theory, because I |
36 |
do not have access to mips64r* hardware) run o32 just fine. |
37 |
|
38 |
You can compile o32 with higher ISAs, i.e., mips3 and mips4, but it's always |
39 |
been debatable how much extra that helps you (Debian used to question our logic |
40 |
on this back in the day). Can't use 64-bit features of 64-bit CPUs via that, |
41 |
but it is supposed to enable things like the square-root instructions available |
42 |
at the mips4 level. |
43 |
|
44 |
The only reason I'm still running o32 is I just haven't been motivated enough |
45 |
to do a full re-install of both systems. Even if I switch to n32, I'll |
46 |
probably keep o32 chroots around just to make sure things don't break there. |
47 |
Might do this soon, though, as I just bought ten new hard drives for all of my |
48 |
MIPS systems. Just need to get the right brackets for them (because they're |
49 |
2.5" 10K SCA drives) so I can mount everything and do data migration. |
50 |
|
51 |
|
52 |
>> |
53 |
>> Correct me if wrong, but it seems the core problem here is that multilib |
54 |
>> inherits from the o32 base profile. While I think the proper longterm fix is |
55 |
>> to have more discrete, modular/pluggable profile components (like OOP and |
56 |
>> multiple base classes), that's not going to happen in Portage for a long time. |
57 |
> |
58 |
> Not exactly. The problem is that everything inherits from profiles/arch/mips |
59 |
> and currently that forces o32 with mgorny's multilib stuff. We need to get |
60 |
> that out of the way for the other profiles that inherit it. |
61 |
> |
62 |
|
63 |
Agreed. This worked fine in the past when o32 was our primary focus and |
64 |
n32/n64 were still experimental (and multilib didn't exist). Nowadays, the |
65 |
base profile shouldn't prescribe a default ABI at all. That needs to be |
66 |
handled under a subprofile somehow. |
67 |
|
68 |
The real problem is Portage's stacking profiles feature, while soving a lot of |
69 |
problems that the previous profile system had, wasn't thought up with all of |
70 |
MIPS' happyfun included. Because endianness, ABI, ISA, kernel, libc, compiler, |
71 |
and even specific machine support can all be interchangeable in MIPS, this |
72 |
causes the stacking profile system to become a thing that would frighten |
73 |
Yog-Sothoth itself, if we were to fully implement all of the combinations |
74 |
possible under this system. |
75 |
|
76 |
|
77 |
>> So I think the solution is to split the profiles into "mips" and "mips64", |
78 |
>> i.e., 32/ and 64/ under the 'mips' base profile folder. 32/ contains |
79 |
>> everything needed to run pure o32-only under either a mips or mips64 kernel. |
80 |
>> I.e., mips-unknown-linux-gnu CHOST. So on my Octane, /etc/portage/make.profile |
81 |
>> symlinks to /usr/portage/default/linux/mips/32/<VERSION>/ |
82 |
> |
83 |
> That's one approach, but I'm trying to find the least intrusive. I do have the |
84 |
> problem fixed with the following: |
85 |
> |
86 |
> [1] default/linux/mips/13.0/o32 |
87 |
> [2] default/linux/mips/13.0/n32 |
88 |
> [3] default/linux/mips/13.0/n64 |
89 |
> [4] default/linux/mips/13.0/multilib/o32 |
90 |
> [5] default/linux/mips/13.0/multilib/n32 |
91 |
> [6] default/linux/mips/13.0/multilib/n64 |
92 |
> [7] default/linux/mips/13.0/mipsel/o32 |
93 |
> [8] default/linux/mips/13.0/mipsel/n32 |
94 |
> [9] default/linux/mips/13.0/mipsel/n64 |
95 |
> [10] default/linux/mips/13.0/mipsel/multilib/o32 |
96 |
> [11] default/linux/mips/13.0/mipsel/multilib/n32 |
97 |
> [12] default/linux/mips/13.0/mipsel/multilib/n64 |
98 |
> |
99 |
> and would like to push this through as a fix for now. 1 and 4 have |
100 |
> CHOST=mips-unknown-linux-gnu and mipsel-unknown-linux-gnu respectively. 2,3 |
101 |
> and 8,9 have mips64-unknown-linux-gnu and mips64el-unknown-linux-gnu |
102 |
> respectively. Only users of profiles 1 and 7 need to change their sym link one |
103 |
> level down to ../o32. That was necessary to move the o32 stuff out of the way |
104 |
> of profiles/arch/mips. |
105 |
|
106 |
This sounds reasonable. I've got the Octane tasked again on building glibc to |
107 |
hunt down the R10000 bug I've been stuck on for the past three months, but I |
108 |
can sync later and test this under your hardened overlay...maybe. I just tried |
109 |
overlays on Gentoo/FreeBSD for nigoro's 9.3 profiles and gave up in utter |
110 |
frustration. |
111 |
|
112 |
I still think these need to be under a separate versioned directory structure, |
113 |
though. 14.0/ or 15.0/ or testing/ or pikachu/, whatever. Then we mark 13.0 |
114 |
as deprecated and allow time for users to migrate off before purging them out |
115 |
of the tree in a month or two. It makes for a messy commit (thanks, CVS), but |
116 |
it avoids breaking people's systems out there who may not be on this mailing list. |
117 |
|
118 |
Also, we should get a news item added as well, specific to MIPS systems only. |
119 |
|
120 |
|
121 |
>> |
122 |
>> 64/ is where the fun is at. I think the default ABI there should be n32 at the |
123 |
>> base, with a subprofile for multilib that itself contains subprofiles to handle |
124 |
>> the combinations of ABIs desired. Still have to workout what CHOST you use for |
125 |
>> the base (GNU standard for n32 is mips64-unknown-linux-gnueabin32). multilib |
126 |
>> would just use mips64-unknown-linux-gnu, and -mabi would be passed to gcc to |
127 |
>> pick the ABI to build for. |
128 |
>> |
129 |
>> Also, if we are going to do any kind of reorganizing of the profiles, let's not |
130 |
>> do it under 13.0. Personally, I'd like to get away from datestamps as profile |
131 |
>> versions (13.0 refers to 2013) and either pick a fixed version number that we |
132 |
>> increment or come up with some other kind of versioning scheme. Or just do |
133 |
>> away with it altogether and have something like a "stable" profile where things |
134 |
>> work and an "unstable" branch that only exists when we're doing insane changes |
135 |
>> to the profiles, which after testing, becomes "stable" (and current "stable" |
136 |
>> becomes "oldstable" or such). |
137 |
>> |
138 |
>> If we have to stick with datestamped versions, then use 15.0. Cause it'll be |
139 |
>> 2015 by the time this goes active. |
140 |
>> |
141 |
>> rough draft of the top-level layout. Doesn't care about chosen libc, ISA, or |
142 |
>> <VERSION>, but does reflect endianness. |
143 |
>> |
144 |
>> default/linux/mips |
145 |
>> | |
146 |
>> |-32/ |
147 |
>> | |-be/ |
148 |
>> | |-le/ |
149 |
>> | |
150 |
>> |-64/ |
151 |
>> | |-be/ |
152 |
>> | |-le/ |
153 |
>> | | |
154 |
>> | |-multilib/ |
155 |
>> | | |-be/ |
156 |
>> | | |-le/ |
157 |
>> | | |
158 |
>> | |
159 |
>> |
160 |
> |
161 |
> I like this, but the problem is disentangling the situation under arch/mips, |
162 |
> not under default/linux/mips. Again, the inheritance problem stems from |
163 |
> everything under profiles/arch/mips inheriting from profiles/arch/mips. So |
164 |
> even if you do implement the above, you still have to address the issue of how |
165 |
> the arch/mips stuff is stacking. |
166 |
|
167 |
I'll poke around arch/mips later and see if some of this can't be extruded |
168 |
there. I don't know if arch/mips is for us exclusively, or if we share it with |
169 |
a few other project teams (other than -embedded -- do we have an OpenBSD MIPS |
170 |
team or such??). |
171 |
|
172 |
|
173 |
-- |
174 |
Joshua Kinard |
175 |
Gentoo/MIPS |
176 |
kumba@g.o |
177 |
4096R/D25D95E3 2011-03-28 |
178 |
|
179 |
"The past tempts us, the present confuses us, the future frightens us. And our |
180 |
lives slip away, moment by moment, lost in that vast, terrible in-between." |
181 |
|
182 |
--Emperor Turhan, Centauri Republic |