On Sun, Aug 05, 2018 at 05:48:52PM -0500, Rob Landley wrote: > On 08/05/2018 11:32 AM, Rich Felker wrote: > > On Sun, Aug 05, 2018 at 10:54:56AM -0500, Rob Landley wrote: > >> On 08/04/2018 05:51 AM, Matthew Wilcox wrote: > >>> On Sat, Aug 04, 2018 at 12:47:08PM +0200, Geert Uytterhoeven wrote: > >>>> You do want to readd the __GFP_ZERO flag to the second user of PGALLOC_GFP, > >>>> don't you? > >>> > >>> I missed that! Probably only relevant for SH-64. But yes ... probably better > >>> to make this explicit then: > >> > >> As far as I know sh5/sh-64 never shipped, it was just some prototype hardware > >> that didn't go to production? > > > > I'm not sure about the details, but GCC has removed support and it's > > effectively dead. I would be happy to merge patches removing the > > existing SH-64 stuff in the kernel too. I'm not sure if generality to > > support LP64 should be left in the arch/sh tree for future or if the > > eventual 64-bit j-core should just be done as a separate arch tree; I > > suspect the latter might be cleaner. > > LP64 is mostly just "long fits in a pointer", which is true on 32 bit too. What > extra "lp64" support are you referring to? I'm using the normal definition of LP64 which is "long and pointer are both exactly 64-bits", not "long fits in pointer" or "long and pointer are same size". > It seems like the only architecture with 32 and 64 bit variants that _doesn't_ > have them together is arm? (x86 does, powerpc does, mips does...) Yes, if there's a lot of arch-specific infrastructure for boot time setup, platform devices, behavior of mmu and cache, etc. that's the same for 32- and 64-bit "variants" of an arch, and especially if the 32-bit variant is mostly a legacy userspace that actually runs on 64-bit hardware that's capable of doing both, then there's a good argument for having them use a shared tree. That last part makes sense for SH -- I think we'd certainly want 32-bit userspace to be able to run on a 64-bit kernel. But it seems like it's possible to split that across archs since ARM did. Really it's sort of a historical accident/misfactoring that "user-to-kernel interface for ISA X" and "kernel internals for the machine arch using ISA X" are conflated as the same thing. If this had been done in a more clean manner the "compat syscall" stuff wouldn't be such a mess. Rich
