LoongArch Slackware current bootstrap 项目启动 1. Slackware是什么？ Slackware历史悠久且优秀，它始于1992年，在1993年首次发布，是现存最古老的商业Linux发行版。Slackware致力于成为一个简单整洁的Linux发行版并尽可能的向UNIX靠拢，这使它非常适合想学习Linux或其他类UNIX系统的人。 Slackware的设计理念以简单性，软件纯度，而核心设计则强调上游资源应保持不变。Slackware 中的许多设计选择可以看作是继承了传统 Unix 系统的简单性和KISS 原则的示例。 2. LoongArch Slackware current bootstrap 项目建立的原因是什么？首先需要介绍下为什么选择 Slackware current ：Slackware 官方维护着一个开发版本（Slackware Current），并且不断有新的软件被加入到这个源，用户可以实现类似 Arch Linux 的滚动升级，等到一个开发版本足够稳定，便会发布一个稳定版。项目的建立原因有两个：（1）跟进 LoongArch 上游社区最新状态，让LoongArch开发者和使用者可以使用上游社区最新的技术成果。（2）丰富 LoongArch 平台发行版系统的种类，可以让大家在LoongArch平台上可以开心的玩耍Slackware（后面也希望可以推动上游Slackware支持LoongArch平台）。现在LoongArch 新世界里有： CLFS for LoongArch 、 gentoo 、 archlinux （ Archlinux loongarch64 bbs讨论帖子）、武老师制作的Archlinux 、 debian还在进行中 3. LoongArch Slackware current bootstrap 项目是做什么的，解决什么问题？ LoongArch Slackware current bootstrap 项目是把Slackware进行移植到LoongArch平台，项目的目标是在LoongArch平台使用Slackware可以和x86平台一样的用户体验。 4. LoongArch Slackware 的 ARCH 选择与思考： BBS讨论帖：此问题详细讨论地址个人见解是distro的ARCH讨论还需要继续，问题还可以深入讨论的必要，这个问题会影响后续上游LoongArch 发行版规范，但此项目需要继续前进，所以本人决定，先以"ARCH=loongarch64" 验证构建方法可靠性，后续会有变化，此ARCH非最终定论综合考虑，本项目移植LoongArch Slackware 选择ARCH=loong64 5. 项目源码地址： https://github.com/slackwarecn/slackware-loongarch64 6. 发布v0.1:LoongArch-slackware64-current-bootstrap-20220708：详细信息请看 Release v0.1 7. Slackware LoongArch 20220708桌面图形构建完成：基于v0.1:LoongArch-slackware64-current-bootstrap-20220708 状态，图形桌面截图展示 8. 发布 v0.3:slackware-current-bootstrap-2022.10.12-loong64 9. 发布slackware current mini install 镜像： slackware64-current-loong64-20221122-mini-install.iso 后面我会在此处，放上我从头移植LoongArch Slackware的成果和展示，欢迎大家来此处讨论 LoongArch Slackware ，此帖持续更新中最后感谢上游LA开发者们的讨论，让我对移植到新架构上发行版，有了更多的认识，过程中有很多注意事项，比如代码规范、各核心基础软件和发行版ARCH的选择、上游社区的沟通方式等，这些问题的思考让我对发行版的整体有了更深的认识。

4.LoongArch Slackware 的 ARCH 选择与思考：欢迎大家针对发行版ARCH的名字选择在此讨论: 最近看到LA开发者们对发行版ARCH的讨论，事后我对ARCH进行了思考。因为现在考虑64位，LoongArch Slackware 的 ARCH 有以下几个选择，我把当时讨论的几个ARCH列出来：（1）ARCH=loongarch64 ，我从开始就喜欢loongarch64，所以我之前移植好的 LoongArch archlinux 使用的是loongarch64，现在想想它的长度太长了，所以我需要再慎重考虑下ARCH的选择 loongarch64) export ARCH=loongarch64 （2）ARCH=loong64 上游社区LoongArch 的go、v8使用了ARCH=loong64，并且上游 LoongArch gentoo （WANG Xuerui (xen0n) 大佬推动维护的LoongArch gentoo）也是使用 loong64（首次使用）的发行版 loongarch64) export ARCH=loong64 （3）ARCH=la64 ，和ia64太像了 loongarch64) export ARCH=la64 （4）ARCH=l64 ，容易和数字“164”*（一六四）看混，增加了观看人的辨识难度 loongarch64) export ARCH=l64 下面是使用上面列举的 ARCH 打包后的表现： 0 root:~/binutils # ls -al /tmp/binutils-2.38-* -rw-r--r-- 1 root root 4347652 Jun 27 09:42 /tmp/binutils-2.38-l64-3.txz -rw-r--r-- 1 root root 4344636 Jun 27 09:36 /tmp/binutils-2.38-la64-3.txz -rw-r--r-- 1 root root 4304680 Jun 27 09:52 /tmp/binutils-2.38-loong64-3.txz -rw-r--r-- 1 root root 4304728 Jun 27 09:37 /tmp/binutils-2.38-loongarch64-3.txz 所以综合考虑，本项目移植LoongArch Slackware 选择ARCH=loong64 （待定）欢迎大家针对发行版ARCH的名字选择在此讨论

尤其是在一些上游代码使用loongarch来判断平台的时候，架构名称上的统一，不容易产生疑义

杜比哈哈，我理解你的顾虑，这个发行版里的ARCH涉及打包后缀的变化，和代码中的架构判断不相关，所以代码里的判断是loongarch ，现在也还是判断loongarch

大道无形若水 go 使用 loong64 有其不得已而为之，但就发行版系统架构而言，和内核高度统一总是好的！

杜比感觉需要 @xen0n 白老师给我们普及下发行版ARCH的选择与思考 😀

在我看来，这不需要选择，除非不得已

大众认知都是loongarch ,极少数使用loong ,我选择loongarch64(除非能统一到loong64)

论相似，loong我觉得跟long也挺像的。

LoongArch Slackware current bootstrap 项目启动: Page 3

LoongArch Slackware current bootstrap 项目启动

杜比

xen0n

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

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

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

xen0n

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

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

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

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

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

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

杜比

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

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

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

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

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

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

xen0n

杜比赞同了。

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

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

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

Yuno

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

lingfengzhe

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

REDEAST

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

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

xen0n

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）的角度，倒也是一件好事。。

xen0n

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时期，但又有简单的包管理器去控制系统，真的太爽啦！！！

时空质能

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

大道无形若水

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

软件依赖问题，就是基础工具软件编译一般都已烂熟于心、其他库软件，按编译时提示进行编译，不用死记硬背，做多了就熟悉了
自动化工具方面，我都是做哪个发行版现写，其实也都算不上自动化，具体可以参考lfs、alfs，

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

狗剩

我感觉简写成la64不错

lingfengzhe

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

大道无形若水

LoongArch Slackware current 最新进展：

exxxxkc

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

本站文章除其作者特殊声明外，一律采用CC BY-NC-SA 4.0许可协议进行授权。
进行转载或二次创作时务必以相同协议进行共享，严禁用于商业用途。