Re: [PATCH] sh: remove unneeded constructor.

Hi Rich,

CC Arnd

On Mon, Aug 6, 2018 at 1:34 AM Rich Felker [off-list ref] wrote:

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

quoted

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".

quoted

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.

Obviously you know more about eventual 64-bit j-core support than me,
but if you intend to run 32-bit userspace on 64-bit j-core, having it
shared makes sense, especially if you'll maintain both.

On the platform side, there will be a big difference between mostly legacy
SH and new DT-based j-core on the 32-bit bit side, and mostly new DT-based
j-core on the 64-bit side.

Arnd probably has a better view on this.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds