/srv/irclogs.ubuntu.com/2005/09/22/#ubuntu-toolchain.txt

=== lamont [n=lamont@15.238.5.82] has joined #ubuntu-toolchain
infinitylamont : Feh, if 'linux32 uname -m' on parisc64 is returning parisc64, not parisc, then parisc64 personalities are broken.  I was almost sure that had been addressed long ago, but maybe not (I never owned a parisc64 machine, so this was all from memory)04:13
infinityMy parisc machine was a lowly 32-bit C200.04:13
infinitylamont : Pretty please, with sugar on top, pester linux-parisc upstream to fix 32/64 kernel personalities, push the patch upstream, and use that patch on your buildd.  :)04:17
lamontinfinity: parisc _ALWAYS_ returns parisc6404:17
lamontalways has (on a 64-bit kernel_)04:17
infinityNo it doesn't.  Only when running a parisc64 kernel.04:17
lamontthat's what I said. :-)04:17
infinityAnyhow, it's broken.  It shouldn't.  That's what personalities are for (it's ALL they're for)04:17
infinityWe just got it fixed for ppc/ppc64 in 2.6.12, now it's your turn. :)04:18
lamontyeah - jbailey's going to beat on the parisc folks, but in the mean time, we'll just do the hack to klibc that has been done everywhere else04:18
infinity<nod>04:18
infinityI assume you had line-of-sight (and perhaps line-of-office-supply-tossing) with some parisc kernel guys.04:19
infinitys/assume/assumed/04:19
lamontwell... certainly when I have a mirror...04:19
lamontbut the issue here is talking to the folks that did the implementation, and figuring out what it really should be saying when.04:20
infinityIf so, tell them to search lkml for ppc64 and uname over the last 4 or 5 months.  Should tell them what to fix. :)04:20
lamontand it's not something to change right now...04:20
infinity(I could provide a patch, but have no way to test anything)04:20
lamontesp since we can't build/install the new (fixed) ubuntu kernel until we have a working klibc...04:20
=== infinity wonders idly if this is also broken on s390/s390x..
lamontjbailey wondered the same thing, and ran away screaming at 31-bit worlds04:22
lamontor something like taht04:22
infinityI think arm/arm64 is okay.04:22
infinityYeah, I don't think s390 would bother with a "linux31" binary, they'd just pretend to be 32-bit and carry on. :)04:22
jbaileyinfinity: The fix is almost tribial, but not quite.04:23
jbaileyinfinity: They use the personality to change how they handle signals internally.04:23
jbaileyIt's almost certainly not what they meant.04:23
infinityOh, FUN.04:23
jbaileyI think I have it mapped out as to what needs to change.04:23
jbaileyI'm going to sleep on it and do it then.  I have klibc for lamont already.04:23
jbaileyJust need to hand it to fabio, and then I think that's done for breezy.04:24
jbailey(unless someone comes up with another !@#$ing filesystem they want to use as a root one)04:24
=== lamont mutters about big kernel changes right before release...
infinityWell, there's no docs (afaik) saying you can't extend the use of personalities to do other neat hacks/tricks, just what they SHOULD do (fool userspace into believing you're on a 32/64 bit kernel when you're not)04:24
lamontoh, klibc, not the kernel.04:24
lamontnm04:24
jbaileyinfinity: What they've done in this case is assume that a 32 bit binary means you want a 32 bit personality.04:25
jbaileyinfinity: I think.  I'm having trouble tracing some of this code. =)04:25
infinityThat's possibly reasonable.04:25
=== lamont waits for his 2.4-kernel-possessing knoppix 3.7 ISO to burn, then he's gonna reboot and head home
jbaileyIt's not how sparc and ppc do it.04:25
infinityBut they're still not munging uname output, which is the issue.04:25
infinityNo, it's not what sparc and ppc do in the slightest, but it seems a valid extension to the use of personalities.04:26
jbaileysparc and ppc set a threadinfo variable with the info.04:26
jbaileyWhich frightens me to think that they might have PER THREAD shit^Wstuff going on.04:26
infinityI suppose this is where I start being greatful that Motorola never announced a 68k-64 CPU.04:26
jbaileyinfinity: Probably.  a 4 mhz 64 bit CPU would really suck for data loads.04:27
lamonthehe04:27
infinity<grin>04:27
lamont64-bit 805104:27
jbaileyI still like the idea of just runnign the whole m68k buildd in a nice emulated environment on a large ia64 machine. 04:28
infinityHey, if they opened up the specs, any goober with access to fab flipchips could get the 68060 scaled ridiculously high, I'm sure.04:28
infinityIt's just that Motorola never upgraded their fabrication, ever.  New ones are still the old ceramic things you can clock peopl ein the head with.04:28
jbaileyWhy should they, really?  If you wanted a small 32 bit chip, the i386 is good enough.04:28
jbaileyLast I checked they were still producing those by the assload.04:29
infinity<nod>04:29
infinityWell, Motorola still produces 68k stuff by the assload too, just not the desktop chips.04:29
jbaileyYEah, they still have the embedded medical market.04:29
infinityThe more popular all-in-one stuff with fancy multimedia controllers and such (but, oddly, no MMU) are in high production still.04:29
lamontwell, I'm off04:30
jbaileyg'n LaMont04:30
infinityLater.04:30
jbaileyinfinity: The other reason in particular that magic isn't a good idea is that it means that all 32 bit binaries would always report parisc from newuname04:38
infinityYes, including a 32-bit 'linux64' binary.04:45
infinityThat would definitely seem wrong.04:45
=== lamont-away grumbles at doko for uploading gcc-3.3 without switching hppa to expect-tcl8.3
dokolaon-taway, ohh, yes, something I forgot ... is it a FTBFS?09:46
dokolamont-away: ^^^09:46
=== doko_ [n=doko@dsl-084-059-088-000.arcor-ip.net] has joined #ubuntu-toolchain
lamont-awaydoko: well, I can babysit it through, but yeah06:31
dokolamont-away: no need, m68k died, so I have to reupload06:39
=== Seveas [n=seveas@seveas.demon.nl] has joined #ubuntu-toolchain
=== Seveas [n=seveas@seveas.demon.nl] has joined #ubuntu-toolchain
=== Seveas [n=seveas@seveas.demon.nl] has joined #ubuntu-toolchain

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!