LA UOSC

xen0n

我和龙芯一毛钱关系没有，这是其一，能拿这个来质疑，我只能呵呵

第二，龙芯推出的这个指令集，它有名字，有中英文手册，而不是和社区说，“嗨，我弄了个指令集，名字大家随意叫”

第三，哪句话有民族情绪了？请指出，别乱扣帽子！

杜比 我和龙芯一毛钱关系没有，这是其一，能拿这个来质疑，我只能呵呵

我承认，这是辩论话术，因为你显得非常为龙芯辩护，尽管他在这一方面并不很受待见。并且似乎我和楼主从上游角度的解释仍然并不为你和你观点的支持者所认同，因此我觉得辩论不容易进行下去。

杜比 第二，龙芯推出的这个指令集，它有名字，有中英文手册，而不是和社区说，“嗨，我弄了个指令集，名字大家随意叫”

前面应该已经提到至少两三遍了，默认大家也都是叫全称的。本身目前现状也是只有在上游已有命名规范的时候，才不叫 loongarch。目前所有不叫全称的地方都是因为上游有明确观点不支持长名字。没喷点

杜比 第三，哪句话有民族情绪了？请指出，别乱扣帽子！

这是针对 @龙芯中科 的，不是针对你。放轻松。

回到主题，关于ARCH的选择，我依然是这样的一个观点：

尊重龙芯，尊重上游，求同存异！

既然龙芯有手册，有官方的中英文名称，那么要做基于loongarch的发行版，就尽量到上游去争取使用这个名字。

开源社区本身就是在不断的争执和竞争中发展起来的，有理有据争取也是对技术的尊重。

所以，期望参与讨论的开源爱好者们，别带情绪，据理力争，有事说事，共建社区交流氛围

毕竟，沟通，是求同存异，消弭误解的有效桥梁！

杜比 赞同了。

再次重复一遍，目前据我所知，即使利益无关的第三方开发者对 LoongArch 的移植行动，就架构命名而言，也以 loongarch / LoongArch / LOONGARCH 为优先，但上游明确表示需要较短名称的情况除外，此时会一致选择尊重上游现存代码风格。

至于龙芯员工向上游提交代码的情况，先前确实存在有不尊重上游现状，甚至明显错误（例如认为所有 MIPS 都是龙芯，抄 MIPS 做 LoongArch 移植，认为只要 LoongArch 就是 64 位，等等）的情况存在，这些只要被发现，无一例外都会被以相同标准，一视同仁地被要求修改，当然最后谁有道理听谁的。不要对这个情况有微词，社区开发者往龙芯的库提交代码被无理由驳回甚至直接晾一边的情况也不少，彼此彼此而已。

最后，吵起来可比一声不吭、闭门造车、自绝于群众（不光国际群众，中国群众之前他们也绝）好太多了。珍惜现状并基于此再向前进才是好的。

很喜欢最后大家的意见。有争吵比没争吵绝对要好很多。一定要放下傲慢的态度，也不要用国产情怀当盾牌，关起门自己玩。技术的事情最后一定要归技术。

其实我不明白为什么不学习arm，使用LArch这种名称呢

lingfengzhe 看完整个帖子，你就会发现，有些东西xen0n已经说得很清楚了。有些东西就是中英文习惯的问题。就像表头是架构名（类型），里面其他是ARM，X86，MIPS，Loong，这样就感觉很正常。你叫Loongarch就显得冗长 。所以我个人的建议，能完整用的时候就Loongarch，需要缩写的时候就Loong。

PS：感觉大家对完整写法没有意见，现在成了讨论缩写规范了。

lingfengzhe 其实我不明白为什么不学习arm，使用LArch这种名称呢

曾经就是 larch，有的地方现在还是：例如工具链里的重定位类型。（没错，龙芯中科自己就搞不一致，一边 loongarch 一边又 LARCH。之前跟他们提过要不要改 LOONGARCH 或者 LOONG 被明确拒绝了，而且没实质理由。说法大致是“工具链项目统一使用 larch”但没有给出其他原因。）

至于曾经使用过 larch 的证据，在极早期的一些龙芯工具链 fork 项目中可以窥见端倪：例如龙芯的 Go 1.15.6 fork，第一个 fork 提交使用的名字就是 GOARCH=larch64。

后边直到提交上游前夕，才批量替换成 loongarch64。再后来的事情大家也都知道了，他们批量替换了第三次。。

按说，龙芯注册了 LArch 的商标，应该用起来，或者至少早些时候就开始宣传以此作为 LoongArch 的简称才对。结果他们并没有。。LArch 也基本被世人遗忘。现在已经没有机会回去了，较短名称已经到处都在用 loong 了。从推广中国龙文化（Loong != Dragon）的角度，倒也是一件好事。。

REDEAST 感觉大家对完整写法没有意见，现在成了讨论缩写规范了。

这个也是没办法的事情，他们工具链上提前占位了 loongarch64-unknown-linux-gnu 了，unknown 的部分大家都一样（历史原因），后边大家也一样，就是前面太 tm 长了。可能是搞 mips64el 多了不觉得 loongarch64 长了，毕竟 MIPS R6 更长：mipsisa64r6el 表示 MIPS64r6 小端。除此之外，差不多长的架构也就 microblaze 这种了，LA 绝对是可预见的未来“常见”架构里名字最长的了。

既然 GNU target tuple 事实上已经定下来了，那为了一致，只好尽量在别的地方厚着脸皮往里推了。当时在 review systemd 代码的时候，纠结半天，还是用 ARCHITECTURE_LOONGARCH64，很难绷住，最后整个文件一大片定义都重新做了遍垂直对齐。。

https://github.com/loongarch64/systemd/pull/5

https://github.com/systemd/systemd/pull/21288/files

Larch 替换了三次说明他们在做之前都没想好，或者公司宣传口的变化，或者没有意识到这是个问题。

至于对齐，其实不算个事，这个对齐都是长的加进来慢慢变的。

大道无形若水 龙芯64位架构

lx64类比 sw64

时空质能 下划线发不出来

5.LoongArch Slackware current bootstrap项目源码地址：https://github.com/shipujin/slackware-loongarch64

6.发布v0.1:LoongArch-slackware64-current-bootstrap-20220708：详细信息请看 Release v0.1

LoongArch slackware64 current 运行信息

LoongArch slackware64 current系统使用的核心基础软件三件套(除glibc使用的是github下的loongson/glibc)，像gcc、binutils、linux-headers都是使用上有社区release版本，具体软件版本可查阅项目的Release/v0.1

最近我在玩LoongArch Slackware，都想仰天长啸，太爽了

因为Slackwae是一个编译打包（编译过程中缺失会正常输出缺失的东西）、安装、移除软件不提示依赖关系的

所以在构建LoongArch Slackware64 current bootstrap时，我想编译啥编译啥，完全不像移植其他distro时被发行版自身识别的依赖搞得烦躁，

构建LoongArch Slackware完全随身所欲(个人需谨慎(狗头，自我发挥性高，让我有种回到了LFS时期，但又有简单的包管理器去控制系统，真的太爽啦！！！

大道无形若水 软件依赖问题怎么解决？还有大佬，你的自动交叉编译工具能放出来吗？学习学习

时空质能 依赖问题怎么解决？还有大佬，你的自动交叉编译工具能放出来吗？学习学

1. 软件依赖问题，就是基础工具软件编译一般都已烂熟于心、其他库软件，按编译时提示进行编译，不用死记硬背，做多了就熟悉了

2. 自动化工具方面，我都是做哪个发行版现写，其实也都算不上自动化，具体可以参考lfs、alfs，

   ( 需要的参考的话，后面我把之前fork的archlinux的自动化工具，适配为loongarch64的自动化工具分享出来

我感觉简写成la64不错

狗剩 如果说写简写，感觉不如LARCH64

LoongArch Slackware current 最新进展：

lingfengzhe

W̶h̶y̶ ̶n̶o̶t̶ ̶c̶a̶l̶l̶ ̶i̶t̶ ̶T̶C̶O̶A̶ ̶(̶t̶h̶e̶ ̶c̶h̶i̶n̶a̶ ̶o̶w̶n̶s̶ ̶a̶r̶c̶h̶i̶t̶e̶c̶t̶u̶r̶e̶)̶ ̶ ̶o̶r̶ ̶T̶C̶A̶ ̶(̶t̶h̶e̶ ̶c̶h̶i̶n̶e̶s̶e̶ ̶a̶r̶c̶h̶i̶t̶e̶c̶t̶u̶r̶e̶)̶ ̶?̶