Re: [PATCH] sh: remove unneeded constructor.

[Rich Felker <dalias@libc.org>]

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