On 8/12/21 14:39, Ulrich Mueller wrote:

On Thu, 12 Aug 2021, Michał Górny wrote:

On Thu, 2021-08-12 at 09:21 +0800, WANG Xuerui wrote:

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".

Can we please keep these identifiers short? Currently all ARCH names are
5 characters at most (except prefix, of course). The total length of the KEYWORDS line isn't the main issue here, but tools like eshowkw or
tables in the various web interfaces.

It is also in GLEP 53 if you need a formal reference:
"Note that no limit on the length of both fields in the keyword are
imposed. However, we cannot overemphasize our preference to keep
keywords small and sensible."

It seems the discussion has gone quiet for a while now, so I take that
we choose ARCH=loong over ARCH=loongarch according to GLEP 53?

If that doesn't receive much objection, I'll prepare and send the first
few eclass patches soon.

Ulrich

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 24 Aug 2021, WANG Xuerui wrote:

It seems the discussion has gone quiet for a while now, so I take that
we choose ARCH=loong over ARCH=loongarch according to GLEP 53?

LGTM

If that doesn't receive much objection, I'll prepare and send the
first few eclass patches soon.

We also need to update the conditional in eselect: https://gitweb.gentoo.org/proj/eselect.git/tree/libs/package-manager.bash.in#n70

Does the GNU triplet (i.e. HOSTTYPE in bash) always use "loongarch"
literally, or can it have some suffix?

Ulrich

-----BEGIN PGP SIGNATURE-----

iQFDBAEBCAAtFiEEtDnZ1O9xIP68rzDbUYgzUIhBXi4FAmEksgIPHHVsbUBnZW50 b28ub3JnAAoJEFGIM1CIQV4usjQIANx8aCVRU8vFkfIyo0Ew3Vjv2LY+KCHB3Fbh q/yWW0esi+XWGAQDRmCdUt/84kseAcx4dwtYOEBy3dZ+ElqYyeke0pYeqpEy2zQU ihT72TMwzYWIOGpN46rxsFq1Jx42a2gOvnI214SVZVjh0jcqeHSBRcHP8JHVLdX/ CdmvvFxh8dz4gKxV+8bZ5yWoLsv1U3UIIl/c35CE3p11tw6fL8+SrsELZIeLnJfy Hpn0HqAbJwpw+5oCzdq7KkLyJr47fCZ0VmrKJ944GDjjFKZWG4ygheAkwKx6Ae4c K/M6SYbYvpi8QiWhHeLbFAddpHoVzpiF1TYHSCPcc+gm3YgcWZg=
=pvXj
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Ulrich,


On 2021/8/24 16:46, Ulrich Mueller wrote:

On Tue, 24 Aug 2021, WANG Xuerui wrote:

It seems the discussion has gone quiet for a while now, so I take that
we choose ARCH=loong over ARCH=loongarch according to GLEP 53?

LGTM

If that doesn't receive much objection, I'll prepare and send the
first few eclass patches soon.

We also need to update the conditional in eselect: https://gitweb.gentoo.org/proj/eselect.git/tree/libs/package-manager.bash.in#n70

Thanks for the reminder!

Does the GNU triplet (i.e. HOSTTYPE in bash) always use "loongarch" literally, or can it have some suffix?

According to their earlier reservation[1] and actual vendor system
behavior, there are 3 possible values:

- loongarch64
- loongarch32
- loongarchx32

Only the LP64 ABI is fully supported by the current upstream submission.
The "loongarch32" thing might NOT be compatible with the LP64 ABI,
instead it might be something embedded-oriented, even instruction
subsets supported might differ. The "loongarchx32" is for an
n32/x32-like ABI that doesn't exist yet, and probably will never get implemented.

Accordingly, I think we only have to care about "loongarch64" for now.

[1]: https://git.savannah.gnu.org/gitweb/?p=config.git;a=patch;h=c8ddc8472f8efcadafc1ef53ca1d863415fddd5f

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 24 Aug 2021, WANG Xuerui wrote:

According to their earlier reservation[1] and actual vendor system
behavior, there are 3 possible values:

- loongarch64
- loongarch32
- loongarchx32

Only the LP64 ABI is fully supported by the current upstream submission.
The "loongarch32" thing might NOT be compatible with the LP64 ABI,
instead it might be something embedded-oriented, even instruction
subsets supported might differ. The "loongarchx32" is for an
n32/x32-like ABI that doesn't exist yet, and probably will never get implemented.

Accordingly, I think we only have to care about "loongarch64" for now.

[1]: https://git.savannah.gnu.org/gitweb/?p=config.git;a=patch;h=c8ddc8472f8efcadafc1ef53ca1d863415fddd5f

Patch for eselect included below.

From a49477f39d3f000cc2ca57f18aafbd66656aba05 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?= <ulm@gentoo.org>
Date: Tue, 24 Aug 2021 14:13:08 +0200
Subject: [PATCH] Recognise loongarch*/loong in package-manager lib MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* libs/package-manager.bash.in (arch): Recognise loongarch*/loong.

Signed-off-by: Ulrich M=C3=BCller <ulm@gentoo.org>
---
ChangeLog | 4 ++++
libs/package-manager.bash.in | 3 ++-
2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index dfdfe47..f2ea0b6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2021-08-24 Ulrich M=C3=BCller <ulm@gentoo.org>
+
+ * libs/package-manager.bash.in (arch): Recognise loongarch*/loong.
+
2021-02-17 Ulrich M=C3=BCller <ulm@gentoo.org>
=20
* modules/news.eselect (do_list): Recognise "new" and "all"
diff --git a/libs/package-manager.bash.in b/libs/package-manager.bash.in
index 35a1e11..c32fcb4 100644
--- a/libs/package-manager.bash.in
+++ b/libs/package-manager.bash.in
@@ -1,5 +1,5 @@
# -*-eselect-*- vim: ft=3Deselect
-# Copyright (c) 2005-2020 Gentoo Authors
+# Copyright (c) 2005-2021 Gentoo Authors
#
# This file is part of the 'eselect' tools framework.
#
@@ -76,6 +76,7 @@ arch() {
hppa*) ret=3Dhppa ;;
i?86) ret=3Dx86 ;;
ia64*) ret=3Dia64 ;;
+ loongarch*) ret=3Dloong ;;

On 2021/8/12 00:39, WANG Xuerui wrote:

Hi everyone,

<snip>

## Gentoo porting plans

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.

Because much of the ABI and even some toolchain internals are going
through
VERY fierce debate and rework, obviously the port will remain
experimental
for a long time. Some minimal support should get in tree though; doing so would ease a lot of pain for experimentation. I already hacked my way to generate working crossdev toolchains, and is halfway towards a rootfs
with
working Python (and Portage). I've already independently ported
strace, and
plan to do the same to libffi in the coming days which would give me
Python.

I'll do all work in my own loongson-overlay first, and upstream these
when
appropriate. Eventually I hope to have working crossdev, qemu-user
emulation
and proper catalyst support.

Some kind of "progress update": I've successfully built stage3 and
minimal installation CD for ARCH=loong; ABI_LOONG is not implemented due
to Loongson retracting 32-bit support themselves, this port is 64-bit
only for now, and may remain so forever (depends on Loongson's
intentions). All modifications are made in loongson-overlay[1]; no
ad-hoc patches to main Portage tree is needed after all. My used
catalyst specs are put at [2]; currently all hard-coded and no automation.

I'm going to send patches for review gradually in the following days, as
the holiday here is over; however I'd like to know whether we need to
wait for the upstream merge of toolchain/kernel support before we can
take patches for ARCH=loong, or if there's more prerequisites.


[1]: https://github.com/xen0n/loongson-overlay

[2]: https://github.com/xen0n/releng/tree/loong

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)