[GIT PULL] parisc fixes for kernel v4.19

[GIT PULL] parisc fixes for kernel v4.19

[Helge Deller]

Hi Greg,

please pull a last set of fixes for the parisc architecture for kernel 4.19 from:

  git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.19-3

The major change is for parisc64 to use a 64-bit suseconds_t type to
match what glibc expects for 64-bit userspace. It's an ABI change, but
since we don't have a 64-bit userspace on parisc yet, it won't introduce
a breakage.

Other than that we simply drop unused code and outdated gcc version
checks.

Thanks,
Helge

----------------------------------------------------------------
Arnd Bergmann (1):
      parisc64: change __kernel_suseconds_t to match glibc

Christoph Hellwig (1):
      parisc: remove the dead ccio-rm-dma driver

Helge Deller (1):
      parisc: Use PARISC_ITLB_TRAP constant in entry.S

Masahiro Yamada (1):
      parisc: remove check for minimum required GCC version

 arch/parisc/Makefile                       |   9 --
 arch/parisc/include/uapi/asm/posix_types.h |   3 -
 arch/parisc/kernel/entry.S                 |   2 +-
 drivers/parisc/Makefile                    |   3 -
 drivers/parisc/ccio-rm-dma.c               | 202 -----------------------------
 5 files changed, 1 insertion(+), 218 deletions(-)
 delete mode 100644 drivers/parisc/ccio-rm-dma.c

Re: [GIT PULL] parisc fixes for kernel v4.19

[Greg Kroah-Hartman]

On Tue, Oct 02, 2018 at 11:02:13PM +0200, Helge Deller wrote:
> Hi Greg,
> 
> please pull a last set of fixes for the parisc architecture for kernel 4.19 from:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.19-3
> 
> The major change is for parisc64 to use a 64-bit suseconds_t type to
> match what glibc expects for 64-bit userspace. It's an ABI change, but
> since we don't have a 64-bit userspace on parisc yet, it won't introduce
> a breakage.

Isn't it a bit "late" in the release cycle for such a change?  Why not
do this on the -rc1 release?

> Other than that we simply drop unused code and outdated gcc version
> checks.

Why are those needed now?

thanks,

greg k-h

Re: [GIT PULL] parisc fixes for kernel v4.19

[Helge Deller]

Hi Greg,

On 02.10.2018 23:16, Greg Kroah-Hartman wrote:
> On Tue, Oct 02, 2018 at 11:02:13PM +0200, Helge Deller wrote:
>> please pull a last set of fixes for the parisc architecture for kernel 4.19 from:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.19-3
>>
>> The major change is for parisc64 to use a 64-bit suseconds_t type to
>> match what glibc expects for 64-bit userspace. It's an ABI change, but
>> since we don't have a 64-bit userspace on parisc yet, it won't introduce
>> a breakage.
> 
> Isn't it a bit "late" in the release cycle for such a change?  Why not
> do this on the -rc1 release?

I've tagged it for stable release.
So, it can go in now, or just wait until -rc1 and go in later.
 
>> Other than that we simply drop unused code and outdated gcc version
>> checks.
> 
> Why are those needed now?

The patch in there which is by me changes one line simply cleans up a patch which
went in during the 4.19 merge cycle. So it would be nice to have it
added now before v4.19 gets released.
The other two patches are trivial and just remove dead code.
I rate them all as non-critical, but nice-to-have-in-v4.19. 

If you disagree I'm absolutely fine to wait with all of them 
for the next merge window.

Thanks!
Helge

Re: [GIT PULL] parisc fixes for kernel v4.19

[Greg Kroah-Hartman]

On Tue, Oct 02, 2018 at 11:46:11PM +0200, Helge Deller wrote:
> Hi Greg,
> 
> On 02.10.2018 23:16, Greg Kroah-Hartman wrote:
> > On Tue, Oct 02, 2018 at 11:02:13PM +0200, Helge Deller wrote:
> >> please pull a last set of fixes for the parisc architecture for kernel 4.19 from:
> >>
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.19-3
> >>
> >> The major change is for parisc64 to use a 64-bit suseconds_t type to
> >> match what glibc expects for 64-bit userspace. It's an ABI change, but
> >> since we don't have a 64-bit userspace on parisc yet, it won't introduce
> >> a breakage.
> > 
> > Isn't it a bit "late" in the release cycle for such a change?  Why not
> > do this on the -rc1 release?
> 
> I've tagged it for stable release.
> So, it can go in now, or just wait until -rc1 and go in later.

Why is a major API change a viable stable change?  What bugfix does it
provide?

> >> Other than that we simply drop unused code and outdated gcc version
> >> checks.
> > 
> > Why are those needed now?
> 
> The patch in there which is by me changes one line simply cleans up a patch which
> went in during the 4.19 merge cycle. So it would be nice to have it
> added now before v4.19 gets released.
> The other two patches are trivial and just remove dead code.
> I rate them all as non-critical, but nice-to-have-in-v4.19. 
> 
> If you disagree I'm absolutely fine to wait with all of them 
> for the next merge window.

Normally I only let "bugfixes" into my trees at this point in time.
cleanups always wait for the next -rc1 merge window as that's what it is
there for.  So I'd recommend waiting as well.

I'm more "worried" about the api change listed above.

thanks,

greg k-h

Re: [GIT PULL] parisc fixes for kernel v4.19

[Helge Deller]

On 03.10.2018 00:24, Greg Kroah-Hartman wrote:
> On Tue, Oct 02, 2018 at 11:46:11PM +0200, Helge Deller wrote:
>> Hi Greg,
>>
>> On 02.10.2018 23:16, Greg Kroah-Hartman wrote:
>>> On Tue, Oct 02, 2018 at 11:02:13PM +0200, Helge Deller wrote:
>>>> please pull a last set of fixes for the parisc architecture for kernel 4.19 from:
>>>>
>>>>   git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.19-3
>>>>
>>>> The major change is for parisc64 to use a 64-bit suseconds_t type to
>>>> match what glibc expects for 64-bit userspace. It's an ABI change, but
>>>> since we don't have a 64-bit userspace on parisc yet, it won't introduce
>>>> a breakage.
>>>
>>> Isn't it a bit "late" in the release cycle for such a change?  Why not
>>> do this on the -rc1 release?
>>
>> I've tagged it for stable release.
>> So, it can go in now, or just wait until -rc1 and go in later.
> 
> Why is a major API change a viable stable change?

Of course it's not.
Esp. not if an API has been used already.
IMHO, this case is really different though... 

> What bugfix does it provide?

It fixes that code in stable kernels which would return wrong
time values *if* someone would create a libc for 64-bit parisc
and would run it with those "stable" kernels.
Fixing it now has no side-effects, the change is a trivial
2-line-removal patch, would bring the code in sync with
newer kernel source code, and it really fixes existing code. 

I still believe that this justifies for a backport.

Nevertheless, if you really disagree, I'm fine dropping the 
backport to stable and will only push it in the next
merge window for v4.20.
 
>>>> Other than that we simply drop unused code and outdated gcc version
>>>> checks.
>>>
>>> Why are those needed now?
>>
>> The patch in there which is by me changes one line simply cleans up a patch which
>> went in during the 4.19 merge cycle. So it would be nice to have it
>> added now before v4.19 gets released.
>> The other two patches are trivial and just remove dead code.
>> I rate them all as non-critical, but nice-to-have-in-v4.19. 
>>
>> If you disagree I'm absolutely fine to wait with all of them 
>> for the next merge window.
> 
> Normally I only let "bugfixes" into my trees at this point in time.
> cleanups always wait for the next -rc1 merge window as that's what it is
> there for.  So I'd recommend waiting as well.

Ok.

Helge

Re: [GIT PULL] parisc fixes for kernel v4.19

[Greg Kroah-Hartman]

Adding Arnd as he wrote the patch in question here...

On Wed, Oct 03, 2018 at 04:47:30PM +0200, Helge Deller wrote:
> On 03.10.2018 00:24, Greg Kroah-Hartman wrote:
> > On Tue, Oct 02, 2018 at 11:46:11PM +0200, Helge Deller wrote:
> >> Hi Greg,
> >>
> >> On 02.10.2018 23:16, Greg Kroah-Hartman wrote:
> >>> On Tue, Oct 02, 2018 at 11:02:13PM +0200, Helge Deller wrote:
> >>>> please pull a last set of fixes for the parisc architecture for kernel 4.19 from:
> >>>>
> >>>>   git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.19-3
> >>>>
> >>>> The major change is for parisc64 to use a 64-bit suseconds_t type to
> >>>> match what glibc expects for 64-bit userspace. It's an ABI change, but
> >>>> since we don't have a 64-bit userspace on parisc yet, it won't introduce
> >>>> a breakage.
> >>>
> >>> Isn't it a bit "late" in the release cycle for such a change?  Why not
> >>> do this on the -rc1 release?
> >>
> >> I've tagged it for stable release.
> >> So, it can go in now, or just wait until -rc1 and go in later.
> > 
> > Why is a major API change a viable stable change?
> 
> Of course it's not.
> Esp. not if an API has been used already.
> IMHO, this case is really different though... 
> 
> > What bugfix does it provide?
> 
> It fixes that code in stable kernels which would return wrong
> time values *if* someone would create a libc for 64-bit parisc
> and would run it with those "stable" kernels.
> Fixing it now has no side-effects, the change is a trivial
> 2-line-removal patch, would bring the code in sync with
> newer kernel source code, and it really fixes existing code. 
> 
> I still believe that this justifies for a backport.
> 
> Nevertheless, if you really disagree, I'm fine dropping the 
> backport to stable and will only push it in the next
> merge window for v4.20.

To clarify, you have no users of this api anywhere (hopefully), and so
the patch in question prevents anyone from using the api in the future.
This makes the suseconds_t handling easier for some reason because only
sparc32 is a "problem" now, right?

So I don't see the "bug" that is being fixed here.  I would have pushed
back on the submission for this for the stable trees as well, this isn't
anything that anyone is using, so there's nothing to "fix" that I can
tell.

Yes, doing it in the "future" is fine, to prevent anyone from making
this mistake (are new machines even being made for this arch?)  But I
don't see how this is a -stable issue.

In this series, only the first patch, would seem to be a real fix, but
even that one isn't.  You are just using a #define for a magic number,
one that will never change either way (the define will never change.) So
that too isn't really a fix, just a code cleanup.

So I am strongly inclined to just not take any of these right now.

thanks,

greg k-h

Re: [GIT PULL] parisc fixes for kernel v4.19

[Arnd Bergmann]

On Wed, Oct 3, 2018 at 8:16 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Wed, Oct 03, 2018 at 04:47:30PM +0200, Helge Deller wrote:
> > On 03.10.2018 00:24, Greg Kroah-Hartman wrote:
> > > On Tue, Oct 02, 2018 at 11:46:11PM +0200, Helge Deller wrote:
> > >>
> > >> I've tagged it for stable release.
> > >> So, it can go in now, or just wait until -rc1 and go in later.
> > >
> > > Why is a major API change a viable stable change?
> >
> > Of course it's not.
> > Esp. not if an API has been used already.
> > IMHO, this case is really different though...
> >
> > > What bugfix does it provide?
> >
> > It fixes that code in stable kernels which would return wrong
> > time values *if* someone would create a libc for 64-bit parisc
> > and would run it with those "stable" kernels.
> > Fixing it now has no side-effects, the change is a trivial
> > 2-line-removal patch, would bring the code in sync with
> > newer kernel source code, and it really fixes existing code.
> >
> > I still believe that this justifies for a backport.
> >
> > Nevertheless, if you really disagree, I'm fine dropping the
> > backport to stable and will only push it in the next
> > merge window for v4.20.
>
> To clarify, you have no users of this api anywhere (hopefully), and so
> the patch in question prevents anyone from using the api in the future.
> This makes the suseconds_t handling easier for some reason because only
> sparc32 is a "problem" now, right?
>
> So I don't see the "bug" that is being fixed here.  I would have pushed
> back on the submission for this for the stable trees as well, this isn't
> anything that anyone is using, so there's nothing to "fix" that I can
> tell.
>
> Yes, doing it in the "future" is fine, to prevent anyone from making
> this mistake (are new machines even being made for this arch?)  But I
> don't see how this is a -stable issue.

The issue here is that glibc has in theory supported 64-bit parisc
user space for a long time, but it has never worked because of the
mismatch. It is very likely that there other problems like it that
/also/ prevent it from working.

Between changing kernel or glibc, I think it's clear that the glibc
has made the better choice of being compatible with all other
architectures (except sparc64), so changing the kernel is better
here.

Between fixing it this late, or doing it for the next merge window,
I don't care. There clearly are no users that are affected by it
today, and if there were, this would fix an important bug, both
security (kernel stack information leak) and functionality
(improving accuracy of gettimeofday() from seconds to
microseconds).

Between backporting it to stable or not, I'd be in favor of the
backport: If we ever want to support 64-bit user space on parisc,
then it's better to have stable kernels get the same working
ABI that new kernels have after the fix (and any other fixes we
may require on top). Or to put it another way: If the argument is
that there won't ever be a 64-bit user space for parisc and we don't
care about it, then we'd be better of removing all native 64-bit
syscalls from arch/parisc/kernel/syscall_table.S.

      Arnd

Re: [GIT PULL] parisc fixes for kernel v4.19

[gregkh]

On Wed, Oct 03, 2018 at 09:49:08PM +0200, Arnd Bergmann wrote:
> On Wed, Oct 3, 2018 at 8:16 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Wed, Oct 03, 2018 at 04:47:30PM +0200, Helge Deller wrote:
> > > On 03.10.2018 00:24, Greg Kroah-Hartman wrote:
> > > > On Tue, Oct 02, 2018 at 11:46:11PM +0200, Helge Deller wrote:
> > > >>
> > > >> I've tagged it for stable release.
> > > >> So, it can go in now, or just wait until -rc1 and go in later.
> > > >
> > > > Why is a major API change a viable stable change?
> > >
> > > Of course it's not.
> > > Esp. not if an API has been used already.
> > > IMHO, this case is really different though...
> > >
> > > > What bugfix does it provide?
> > >
> > > It fixes that code in stable kernels which would return wrong
> > > time values *if* someone would create a libc for 64-bit parisc
> > > and would run it with those "stable" kernels.
> > > Fixing it now has no side-effects, the change is a trivial
> > > 2-line-removal patch, would bring the code in sync with
> > > newer kernel source code, and it really fixes existing code.
> > >
> > > I still believe that this justifies for a backport.
> > >
> > > Nevertheless, if you really disagree, I'm fine dropping the
> > > backport to stable and will only push it in the next
> > > merge window for v4.20.
> >
> > To clarify, you have no users of this api anywhere (hopefully), and so
> > the patch in question prevents anyone from using the api in the future.
> > This makes the suseconds_t handling easier for some reason because only
> > sparc32 is a "problem" now, right?
> >
> > So I don't see the "bug" that is being fixed here.  I would have pushed
> > back on the submission for this for the stable trees as well, this isn't
> > anything that anyone is using, so there's nothing to "fix" that I can
> > tell.
> >
> > Yes, doing it in the "future" is fine, to prevent anyone from making
> > this mistake (are new machines even being made for this arch?)  But I
> > don't see how this is a -stable issue.
> 
> The issue here is that glibc has in theory supported 64-bit parisc
> user space for a long time, but it has never worked because of the
> mismatch. It is very likely that there other problems like it that
> /also/ prevent it from working.
> 
> Between changing kernel or glibc, I think it's clear that the glibc
> has made the better choice of being compatible with all other
> architectures (except sparc64), so changing the kernel is better
> here.
> 
> Between fixing it this late, or doing it for the next merge window,
> I don't care. There clearly are no users that are affected by it
> today, and if there were, this would fix an important bug, both
> security (kernel stack information leak) and functionality
> (improving accuracy of gettimeofday() from seconds to
> microseconds).
> 
> Between backporting it to stable or not, I'd be in favor of the
> backport: If we ever want to support 64-bit user space on parisc,
> then it's better to have stable kernels get the same working
> ABI that new kernels have after the fix (and any other fixes we
> may require on top). Or to put it another way: If the argument is
> that there won't ever be a 64-bit user space for parisc and we don't
> care about it, then we'd be better of removing all native 64-bit
> syscalls from arch/parisc/kernel/syscall_table.S.

Ok, then let's treat this like any other arch/driver/subsystem that we
remove.  Drop the file(s) in a -rc1 merge window and then if anyone
object to it later on because they really were using it, you can easily
revert that change.

We do not backport removals of drivers/subsystems/arches to stable
kernels, so this shouldn't happen here either.

thanks,

greg k-h

Re: [GIT PULL] parisc fixes for kernel v4.19

[Helge Deller]

On 04.10.2018 01:02, gregkh wrote:
> On Wed, Oct 03, 2018 at 09:49:08PM +0200, Arnd Bergmann wrote:
>> On Wed, Oct 3, 2018 at 8:16 PM Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>>> On Wed, Oct 03, 2018 at 04:47:30PM +0200, Helge Deller wrote:
>>>> On 03.10.2018 00:24, Greg Kroah-Hartman wrote:
>>>>> On Tue, Oct 02, 2018 at 11:46:11PM +0200, Helge Deller wrote:
>>>>>>
>>>>>> I've tagged it for stable release.
>>>>>> So, it can go in now, or just wait until -rc1 and go in later.
>>>>>
>>>>> Why is a major API change a viable stable change?
>>>>
>>>> Of course it's not.
>>>> Esp. not if an API has been used already.
>>>> IMHO, this case is really different though...
>>>>
>>>>> What bugfix does it provide?
>>>>
>>>> It fixes that code in stable kernels which would return wrong
>>>> time values *if* someone would create a libc for 64-bit parisc
>>>> and would run it with those "stable" kernels.
>>>> Fixing it now has no side-effects, the change is a trivial
>>>> 2-line-removal patch, would bring the code in sync with
>>>> newer kernel source code, and it really fixes existing code.
>>>>
>>>> I still believe that this justifies for a backport.
>>>>
>>>> Nevertheless, if you really disagree, I'm fine dropping the
>>>> backport to stable and will only push it in the next
>>>> merge window for v4.20.
>>>
>>> To clarify, you have no users of this api anywhere (hopefully), and so
>>> the patch in question prevents anyone from using the api in the future.
>>> This makes the suseconds_t handling easier for some reason because only
>>> sparc32 is a "problem" now, right?
>>>
>>> So I don't see the "bug" that is being fixed here.  I would have pushed
>>> back on the submission for this for the stable trees as well, this isn't
>>> anything that anyone is using, so there's nothing to "fix" that I can
>>> tell.
>>>
>>> Yes, doing it in the "future" is fine, to prevent anyone from making
>>> this mistake (are new machines even being made for this arch?)  But I
>>> don't see how this is a -stable issue.
>>
>> The issue here is that glibc has in theory supported 64-bit parisc
>> user space for a long time, but it has never worked because of the
>> mismatch. It is very likely that there other problems like it that
>> /also/ prevent it from working.
>>
>> Between changing kernel or glibc, I think it's clear that the glibc
>> has made the better choice of being compatible with all other
>> architectures (except sparc64), so changing the kernel is better
>> here.
>>
>> Between fixing it this late, or doing it for the next merge window,
>> I don't care. There clearly are no users that are affected by it
>> today, and if there were, this would fix an important bug, both
>> security (kernel stack information leak) and functionality
>> (improving accuracy of gettimeofday() from seconds to
>> microseconds).
>>
>> Between backporting it to stable or not, I'd be in favor of the
>> backport: If we ever want to support 64-bit user space on parisc,
>> then it's better to have stable kernels get the same working
>> ABI that new kernels have after the fix (and any other fixes we
>> may require on top). 

Ack.

>> Or to put it another way: If the argument is
>> that there won't ever be a 64-bit user space for parisc 

FYI, I was planning to try a 64-bit user space at some point.
Just see my recent patches and mails, e.g. 
b6fc0cccb6b35815a7d1cfc9279cdbfc2c61d00d
5b00ca0b8035e49ef7c466e959c5cb457a654351
and
https://www.spinics.net/lists/linux-parisc/msg09070.html

>> and we don't care about it, 

I (and a few others) do care about it.

>> then we'd be better of removing all native 64-bit
>> syscalls from arch/parisc/kernel/syscall_table.S.
> 
> Ok, then let's treat this like any other arch/driver/subsystem that we
> remove.  Drop the file(s) in a -rc1 merge window and then if anyone
> object to it later on because they really were using it, you can easily
> revert that change.

As a maintainer of this port, I object to this.
You suggest to remove a working, functional and maintained interface for no good use.
Removing it won't save lots of bytes in the executable (or source code)
but will make my life as maintainer harder.

Thanks,
Helge

> 
> We do not backport removals of drivers/subsystems/arches to stable
> kernels, so this shouldn't happen here either.
> 
> thanks,
> 
> greg k-h

Re: [GIT PULL] parisc fixes for kernel v4.19

[Arnd Bergmann]

On Thu, Oct 4, 2018 at 10:42 AM Helge Deller <deller@gmx.de> wrote:
> On 04.10.2018 01:02, gregkh wrote:
> > On Wed, Oct 03, 2018 at 09:49:08PM +0200, Arnd Bergmann wrote:
> >> On Wed, Oct 3, 2018 at 8:16 PM Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> wrote:
> >>> On Wed, Oct 03, 2018 at 04:47:30PM +0200, Helge Deller wrote:
> >>>> On 03.10.2018 00:24, Greg Kroah-Hartman wrote:
> >>>>> On Tue, Oct 02, 2018 at 11:46:11PM +0200, Helge Deller wrote:
> >> Or to put it another way: If the argument is
> >> that there won't ever be a 64-bit user space for parisc
>
> FYI, I was planning to try a 64-bit user space at some point.
> Just see my recent patches and mails, e.g.
> b6fc0cccb6b35815a7d1cfc9279cdbfc2c61d00d
> 5b00ca0b8035e49ef7c466e959c5cb457a654351
> and
> https://www.spinics.net/lists/linux-parisc/msg09070.html
>
> >> and we don't care about it,
>
> I (and a few others) do care about it.
>
> >> then we'd be better of removing all native 64-bit
> >> syscalls from arch/parisc/kernel/syscall_table.S.
> >
> > Ok, then let's treat this like any other arch/driver/subsystem that we
> > remove.  Drop the file(s) in a -rc1 merge window and then if anyone
> > object to it later on because they really were using it, you can easily
> > revert that change.
>
> As a maintainer of this port, I object to this.
> You suggest to remove a working, functional and maintained interface for no good use.
> Removing it won't save lots of bytes in the executable (or source code)
> but will make my life as maintainer harder.

Makes sense. I was basing my thoughts on the observation that
nobody did this in the last 18 years that he port has been around,
but if you still plan to do this, then we should not regress.

What is your current estimate for how many more patches
are required to get it working reasonably well? Did you plan
to have commit 5b00ca0b8035 ("parisc: Restore possibility
to execute 64-bit applications") backported to stable kernels,
or just get it working in future versions?
I suppose we either want to backport that patch and mine,
or neither of them.

         Arnd

Re: [GIT PULL] parisc fixes for kernel v4.19

[Helge Deller]

On 04.10.2018 15:34, Arnd Bergmann wrote:
> On Thu, Oct 4, 2018 at 10:42 AM Helge Deller <deller@gmx.de> wrote:
>> On 04.10.2018 01:02, gregkh wrote:
>>> On Wed, Oct 03, 2018 at 09:49:08PM +0200, Arnd Bergmann wrote:
>>>> On Wed, Oct 3, 2018 at 8:16 PM Greg Kroah-Hartman
>>>> <gregkh@linuxfoundation.org> wrote:
>>>>> On Wed, Oct 03, 2018 at 04:47:30PM +0200, Helge Deller wrote:
>>>>>> On 03.10.2018 00:24, Greg Kroah-Hartman wrote:
>>>>>>> On Tue, Oct 02, 2018 at 11:46:11PM +0200, Helge Deller wrote:
>>>> Or to put it another way: If the argument is
>>>> that there won't ever be a 64-bit user space for parisc
>>
>> FYI, I was planning to try a 64-bit user space at some point.
>> Just see my recent patches and mails, e.g.
>> b6fc0cccb6b35815a7d1cfc9279cdbfc2c61d00d
>> 5b00ca0b8035e49ef7c466e959c5cb457a654351
>> and
>> https://www.spinics.net/lists/linux-parisc/msg09070.html
>>
>>>> and we don't care about it,
>>
>> I (and a few others) do care about it.
>>
>>>> then we'd be better of removing all native 64-bit
>>>> syscalls from arch/parisc/kernel/syscall_table.S.
>>>
>>> Ok, then let's treat this like any other arch/driver/subsystem that we
>>> remove.  Drop the file(s) in a -rc1 merge window and then if anyone
>>> object to it later on because they really were using it, you can easily
>>> revert that change.
>>
>> As a maintainer of this port, I object to this.
>> You suggest to remove a working, functional and maintained interface for no good use.
>> Removing it won't save lots of bytes in the executable (or source code)
>> but will make my life as maintainer harder.
> 
> Makes sense. I was basing my thoughts on the observation that
> nobody did this in the last 18 years that he port has been around,
> but if you still plan to do this, then we should not regress.
> 
> What is your current estimate for how many more patches
> are required to get it working reasonably well? 

I'm not aware of missing functionality which requires additional patches
for the Linux kernel.
It's userspace which needs work, e.g. binutils needs to be fixed
to get multiple stub section support, and glibc.

> Did you plan
> to have commit 5b00ca0b8035 ("parisc: Restore possibility
> to execute 64-bit applications") backported to stable kernels,
> or just get it working in future versions?

A backport of this patch is not needed.
The patch fixes the 64-bit loader which I broke a few days before 
when I switched to the generic binfmt implementation with commit
71d577db01a5 ("parisc: Switch to generic COMPAT_BINFMT_ELF").

> I suppose we either want to backport that patch and mine,
> or neither of them.

It's only your patch which I would like to backport.

Helge

Re: [GIT PULL] parisc fixes for kernel v4.19

[Helge Deller]

On 04.10.2018 16:30, Helge Deller wrote:
> On 04.10.2018 15:34, Arnd Bergmann wrote:
>> On Thu, Oct 4, 2018 at 10:42 AM Helge Deller <deller@gmx.de> wrote:
>>> On 04.10.2018 01:02, gregkh wrote:
>>>> On Wed, Oct 03, 2018 at 09:49:08PM +0200, Arnd Bergmann wrote:
>>>>> On Wed, Oct 3, 2018 at 8:16 PM Greg Kroah-Hartman
>>>>> <gregkh@linuxfoundation.org> wrote:
>>>>>> On Wed, Oct 03, 2018 at 04:47:30PM +0200, Helge Deller wrote:
>>>>>>> On 03.10.2018 00:24, Greg Kroah-Hartman wrote:
>>>>>>>> On Tue, Oct 02, 2018 at 11:46:11PM +0200, Helge Deller wrote:
>>>>> Or to put it another way: If the argument is
>>>>> that there won't ever be a 64-bit user space for parisc
>>>
>>> FYI, I was planning to try a 64-bit user space at some point.
>>> Just see my recent patches and mails, e.g.
>>> b6fc0cccb6b35815a7d1cfc9279cdbfc2c61d00d
>>> 5b00ca0b8035e49ef7c466e959c5cb457a654351
>>> and
>>> https://www.spinics.net/lists/linux-parisc/msg09070.html
>>>
>>>>> and we don't care about it,
>>>
>>> I (and a few others) do care about it.
>>>
>>>>> then we'd be better of removing all native 64-bit
>>>>> syscalls from arch/parisc/kernel/syscall_table.S.
>>>>
>>>> Ok, then let's treat this like any other arch/driver/subsystem that we
>>>> remove.  Drop the file(s) in a -rc1 merge window and then if anyone
>>>> object to it later on because they really were using it, you can easily
>>>> revert that change.
>>>
>>> As a maintainer of this port, I object to this.
>>> You suggest to remove a working, functional and maintained interface for no good use.
>>> Removing it won't save lots of bytes in the executable (or source code)
>>> but will make my life as maintainer harder.
>>
>> Makes sense. I was basing my thoughts on the observation that
>> nobody did this in the last 18 years that he port has been around,
>> but if you still plan to do this, then we should not regress.
>>
>> What is your current estimate for how many more patches
>> are required to get it working reasonably well? 
> 
> I'm not aware of missing functionality which requires additional patches
> for the Linux kernel.
> It's userspace which needs work, e.g. binutils needs to be fixed
> to get multiple stub section support, and glibc.
> 
>> Did you plan
>> to have commit 5b00ca0b8035 ("parisc: Restore possibility
>> to execute 64-bit applications") backported to stable kernels,
>> or just get it working in future versions?
> 
> A backport of this patch is not needed.
> The patch fixes the 64-bit loader which I broke a few days before 
> when I switched to the generic binfmt implementation with commit
> 71d577db01a5 ("parisc: Switch to generic COMPAT_BINFMT_ELF").

Actually, to be correct here, backporting my commit 5b00ca0b8035
to v4.17, v4.18 and v4.19 would be the right thing.

>> I suppose we either want to backport that patch and mine,
>> or neither of them.

Agreed. Both would be best.

Helge