From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Hogan Subject: Re: Introducing a nanoMIPS port for Linux Date: Fri, 4 May 2018 14:24:33 +0100 Message-ID: <20180504132432.GA30458@jamesdev> References: <20180502215107.GA9884@saruman> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Arnd Bergmann Cc: Ralf Baechle , "open list:RALINK MIPS ARCHITECTURE" , linux-arch , Linux Kernel Mailing List , Paul Burton , Matt Redfearn , Marcin Nowakowski , Matthew Fortune List-Id: linux-arch.vger.kernel.org --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 03, 2018 at 06:40:07PM -0400, Arnd Bergmann wrote: > On Wed, May 2, 2018 at 5:51 PM, James Hogan wrote: >=20 > > Due to the binary incompatibility between previous MIPS architecture > > generations and nanoMIPS, and the significantly revamped compiler ABI, > > where for the first time, a single Linux kernel would not be expected to > > handle both old and new ABIs, we have decided to also take the > > opportunity to modernise the Linux user ABI for nanoMIPS, making as much > > use of generic interfaces as possible and modernising the true > > architecture specific parts. > > > > This is similar to what a whole new kernel architecture would be > > expected to adopt, but has been done within the existing MIPS > > architecture port to allow reuse of the existing MIPS code, most of > > which does not depend on these ABI specifics. Details of the proposed > > Linux user ABI changes for nanoMIPS can be found here: >=20 > While I haven't looked at the individual changes, I wonder whether > it would be useful to make this new ABI use 64-bit time_t from > the start, using the new system calls that Deepa and I have been > posting recently. Personally I'm all for squeezing as much API cleanup in as possible before its merged, though obviously there'll be a point when the ABI may need to be frozen, at which point we'll mostly have to accept what we have within reason. > There are still a few things to be worked out: > only the first of four sets of syscall patches is merged so far, > and we have a couple of areas that will require further ABI changes > (sound, sockets, media and maybe a couple of smaller drivers), > so it depends on the overall timing. If you would otherwise merge > the patches quickly, then it may be better to just follow the existing > 32-bit architectures and add the 64-bit entry points when we do it > for everyone. I think it'll likely be a couple of cycles before it gets merged anyway. There's still work to do, and limited resources. Cheers James --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQS7lRNBWUYtqfDOVL41zuSGKxAj8gUCWuxfDgAKCRA1zuSGKxAj 8gFKAQDBKIiLApOFjRYGPadIj0pTPL6FcfLozP0XuoIjjwlKdAEAguVMty7TjYS0 +MKImps2UKe+xTw3YLPtnZlk+cVTpQ0= =7SKV -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.kernel.org ([198.145.29.99]:57688 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751114AbeEDNYi (ORCPT ); Fri, 4 May 2018 09:24:38 -0400 Date: Fri, 4 May 2018 14:24:33 +0100 From: James Hogan Subject: Re: Introducing a nanoMIPS port for Linux Message-ID: <20180504132432.GA30458@jamesdev> References: <20180502215107.GA9884@saruman> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Arnd Bergmann Cc: Ralf Baechle , "open list:RALINK MIPS ARCHITECTURE" , linux-arch , Linux Kernel Mailing List , Paul Burton , Matt Redfearn , Marcin Nowakowski , Matthew Fortune Message-ID: <20180504132433.ecJM5_pDPKOwA-CCJa_Va8jWk9bA3cYUFsYpsXMQAPw@z> --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 03, 2018 at 06:40:07PM -0400, Arnd Bergmann wrote: > On Wed, May 2, 2018 at 5:51 PM, James Hogan wrote: >=20 > > Due to the binary incompatibility between previous MIPS architecture > > generations and nanoMIPS, and the significantly revamped compiler ABI, > > where for the first time, a single Linux kernel would not be expected to > > handle both old and new ABIs, we have decided to also take the > > opportunity to modernise the Linux user ABI for nanoMIPS, making as much > > use of generic interfaces as possible and modernising the true > > architecture specific parts. > > > > This is similar to what a whole new kernel architecture would be > > expected to adopt, but has been done within the existing MIPS > > architecture port to allow reuse of the existing MIPS code, most of > > which does not depend on these ABI specifics. Details of the proposed > > Linux user ABI changes for nanoMIPS can be found here: >=20 > While I haven't looked at the individual changes, I wonder whether > it would be useful to make this new ABI use 64-bit time_t from > the start, using the new system calls that Deepa and I have been > posting recently. Personally I'm all for squeezing as much API cleanup in as possible before its merged, though obviously there'll be a point when the ABI may need to be frozen, at which point we'll mostly have to accept what we have within reason. > There are still a few things to be worked out: > only the first of four sets of syscall patches is merged so far, > and we have a couple of areas that will require further ABI changes > (sound, sockets, media and maybe a couple of smaller drivers), > so it depends on the overall timing. If you would otherwise merge > the patches quickly, then it may be better to just follow the existing > 32-bit architectures and add the 64-bit entry points when we do it > for everyone. I think it'll likely be a couple of cycles before it gets merged anyway. There's still work to do, and limited resources. Cheers James --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQS7lRNBWUYtqfDOVL41zuSGKxAj8gUCWuxfDgAKCRA1zuSGKxAj 8gFKAQDBKIiLApOFjRYGPadIj0pTPL6FcfLozP0XuoIjjwlKdAEAguVMty7TjYS0 +MKImps2UKe+xTw3YLPtnZlk+cVTpQ0= =7SKV -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE--