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@xxxxxx> 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@xxxxxxxxxxxxxxxxxxx> 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