Re: [PATCH] sh: remove unneeded constructor.

On Sun, Aug 05, 2018 at 05:48:52PM -0500, Rob Landley wrote:

On 08/05/2018 11:32 AM, Rich Felker wrote:

quoted

On Sun, Aug 05, 2018 at 10:54:56AM -0500, Rob Landley wrote:

quoted

On 08/04/2018 05:51 AM, Matthew Wilcox wrote:

quoted

On Sat, Aug 04, 2018 at 12:47:08PM +0200, Geert Uytterhoeven wrote:

quoted

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