[04:13] <infinity> lamont : 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] <infinity> My parisc machine was a lowly 32-bit C200.
[04:17] <infinity> lamont : 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] <lamont> infinity: parisc _ALWAYS_ returns parisc64
[04:17] <lamont> always has (on a 64-bit kernel_)
[04:17] <infinity> No it doesn't.  Only when running a parisc64 kernel.
[04:17] <lamont> that's what I said. :-)
[04:17] <infinity> Anyhow, it's broken.  It shouldn't.  That's what personalities are for (it's ALL they're for)
[04:18] <infinity> We just got it fixed for ppc/ppc64 in 2.6.12, now it's your turn. :)
[04:18] <lamont> yeah - 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 else

[04:19] <infinity> I assume you had line-of-sight (and perhaps line-of-office-supply-tossing) with some parisc kernel guys.
[04:19] <infinity> s/assume/assumed/
[04:19] <lamont> well... certainly when I have a mirror...
[04:20] <lamont> but the issue here is talking to the folks that did the implementation, and figuring out what it really should be saying when.
[04:20] <infinity> If 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] <lamont> and 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] <lamont> esp since we can't build/install the new (fixed) ubuntu kernel until we have a working klibc...
[04:22] <lamont> jbailey wondered the same thing, and ran away screaming at 31-bit worlds
[04:22] <lamont> or something like taht
[04:22] <infinity> I think arm/arm64 is okay.
[04:22] <infinity> Yeah, I don't think s390 would bother with a "linux31" binary, they'd just pretend to be 32-bit and carry on. :)
[04:23] <jbailey> infinity: The fix is almost tribial, but not quite.
[04:23] <jbailey> infinity: They use the personality to change how they handle signals internally.
[04:23] <jbailey> It's almost certainly not what they meant.
[04:23] <infinity> Oh, FUN.
[04:23] <jbailey> I think I have it mapped out as to what needs to change.
[04:23] <jbailey> I'm going to sleep on it and do it then.  I have klibc for lamont already.
[04:24] <jbailey> Just 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] <infinity> Well, 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] <lamont> oh, klibc, not the kernel.
[04:24] <lamont> nm
[04:25] <jbailey> infinity: What they've done in this case is assume that a 32 bit binary means you want a 32 bit personality.
[04:25] <jbailey> infinity: I think.  I'm having trouble tracing some of this code. =)
[04:25] <infinity> That's possibly reasonable.
[04:25] <jbailey> It's not how sparc and ppc do it.
[04:25] <infinity> But they're still not munging uname output, which is the issue.
[04:26] <infinity> No, it's not what sparc and ppc do in the slightest, but it seems a valid extension to the use of personalities.
[04:26] <jbailey> sparc and ppc set a threadinfo variable with the info.
[04:26] <jbailey> Which frightens me to think that they might have PER THREAD shit^Wstuff going on.
[04:26] <infinity> I suppose this is where I start being greatful that Motorola never announced a 68k-64 CPU.
[04:27] <jbailey> infinity: Probably.  a 4 mhz 64 bit CPU would really suck for data loads.
[04:27] <lamont> hehe

[04:27] <lamont> 64-bit 8051
[04:28] <jbailey> I still like the idea of just runnign the whole m68k buildd in a nice emulated environment on a large ia64 machine. 
[04:28] <infinity> Hey, 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] <infinity> It'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] <jbailey> Why should they, really?  If you wanted a small 32 bit chip, the i386 is good enough.
[04:29] <jbailey> Last I checked they were still producing those by the assload.

[04:29] <infinity> Well, Motorola still produces 68k stuff by the assload too, just not the desktop chips.
[04:29] <jbailey> YEah, they still have the embedded medical market.
[04:29] <infinity> The more popular all-in-one stuff with fancy multimedia controllers and such (but, oddly, no MMU) are in high production still.
[04:30] <lamont> well, I'm off
[04:30] <jbailey> g'n LaMont
[04:30] <infinity> Later.
[04:38] <jbailey> infinity: 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 newuname
[04:45] <infinity> Yes, including a 32-bit 'linux64' binary.
[04:45] <infinity> That would definitely seem wrong.
[09:46] <doko> laon-taway, ohh, yes, something I forgot ... is it a FTBFS?
[09:46] <doko> lamont-away: ^^^
[06:31] <lamont-away> doko: well, I can babysit it through, but yeah
[06:39] <doko> lamont-away: no need, m68k died, so I have to reupload