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? 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
