On Thu, 2021-08-12 at 09:21 +0800, WANG Xuerui wrote: > On 8/12/21 02:13, William Hubbs wrote: > > > On Thu, Aug 12, 2021 at 12:39:33AM +0800, WANG Xuerui wrote: > > > I'm planning to take ARCH=loongarch for the port; and support the LP64 ABI > > > first. I'd like to support both LP64 and ILP32 ABIs, but that's not a > > > priority. > > > The ABI flag might be named "ABI_LOONGARCH" but that's IMO a bit long (pun > > > semi-intended); ARCH=loong and ABI_LOONG might be better, I'm open to > > > suggestions. > > FWIW, I like loong and ABI_LOONG better, or even better would be to use the > > string `uname -m` returns for the hardware as ARCH and as the suffix for > > ABI_. > > Ahh I forgot to mention that... > > $ uname -m > loongarch64 > > And the triple is "loongarch64-unknown-linux-gnu"; kernel port sits at > arch/loongarch; almost everything except Go uses the "loongarch" > version. Go people didn't like duplicating "arch" for their GOARCH > value, so it's "GOARCH=loong64" there, otherwise the Loongson people > pushing their agenda would have used "loongarch64" too. > > I would say this is mostly aesthetic matter, because we have equally > long ARCH names like "microblaze" or "openrisc" too. From a user's > perspective I'd personally prefer "loong" to save some typing, but > "loongarch" wouldn't hurt that much either. >
I think following upstream (i.e. "loongarch" convention) is better. We have already caused some mess with custom names like "arm64". -- Best regards, Michał Górny
