ls232核交叉编译器支持 ubuntu 17 或 ubuntu 16吗

xen0n 回复了问题 • 2 人关注 • 1 个回复 • 41 次浏览 • 2017-11-17 16:14 • 来自相关话题

装不上loongnix-20170726.iso

回复

murat 发起了问题 • 1 人关注 • 0 个回复 • 40 次浏览 • 2017-11-17 10:46 • 来自相关话题

国产CPU的发展不能被老外牵着鼻子走

jiangtao9999 回复了问题 • 3 人关注 • 2 个回复 • 105 次浏览 • 2017-11-16 19:52 • 来自相关话题

wine程序支持龙芯平台吗?

iapcmloongson 回复了问题 • 4 人关注 • 3 个回复 • 176 次浏览 • 2017-11-15 09:55 • 来自相关话题

Chrome60不支持PDF插件?

pengfei 回复了问题 • 4 人关注 • 4 个回复 • 348 次浏览 • 2017-11-14 14:05 • 来自相关话题

arch linux 的 mips64el 版,谁接手?

xen0n 回复了问题 • 2 人关注 • 1 个回复 • 136 次浏览 • 2017-11-12 14:35 • 来自相关话题

由 expat 编译错误揭示的 Loongnix 巨坑,以及由此生发的关于社区互动的思考

xen0n 发表了文章 • 85 个评论 • 707 次浏览 • 2017-11-11 19:28 • 来自相关话题

本人在前一阵子团购的 3A3000 开发板上安装了 Gentoo 系统。但由于一直没有时间移植个人所用的 Linux 补丁,一直用 Loongnix 的 linux-3.10.84 临时顶上内核的位置。一开始用 amd64 机器交叉编译的方式自举了整个基本系统,为了简单起见,没有打开 multilib 支持;在 3A3000 上成功引导之后,再打开了 multilib,安装其他软件,整个过程还算顺利。
 
然而在 10 月份后续更新系统的过程中,马上发现 expat 库永远编译不过,安装过程报 expat_config.h header checksum mismatch,意思是这个文件在不同的 multilib ABI 下内容不一致。但有意思的是,无论是 expat 上游还是 Gentoo 社区都完全找不到这个 bug!当时因为工作比较忙,于是没有深究了。
 
最近虽然工作愈发地忙起来了,但正好想搭建一个 Linux 的本地测试环境,公司的后端又用的 Golang,所以想着放在脚旁边的龙芯很适合。于是 expat 这个库挡住了很多软件的编译,我又不想 pin 住它的版本,所以开始继续研究了。
 
两个文件的差异是这样的:--- ./expat-2.2.5-abi_mips_o32.o32/expat_config.h 2017-11-10 16:07:07.241011603 +0800
+++ ./expat-2.2.5-abi_mips_n64.n64/expat_config.h 2017-11-10 16:07:40.819296062 +0800
@@ -23,7 +23,7 @@
#define HAVE_GETPAGESIZE 1

/* Define to 1 if you have the `getrandom' function. */
-/* #undef HAVE_GETRANDOM */
+#define HAVE_GETRANDOM 1

/* Define to 1 if you have the <inttypes.h> header file. */
#define HAVE_INTTYPES_H 1
@@ -53,7 +53,7 @@
#define HAVE_STRING_H 1

/* Define to 1 if you have `syscall' and `SYS_getrandom'. */
-#define HAVE_SYSCALL_GETRANDOM 1
+/* #undef HAVE_SYSCALL_GETRANDOM */

/* Define to 1 if you have the <sys/param.h> header file. */
#define HAVE_SYS_PARAM_H 1





这是什么情况? o32 ABI 下没有 getrandom 函数,但 n64 下却有?(看了 configure.ac 文件,上边的判断为假才会检测下边那个不一致对应的选项,所以相当于只有一处不一致。)连单个架构下 ABI 都不能保持一致的 syscall 实现,这种代码怎么可能逃过 Linux 各大子系统 maintainers 的法眼,而进入主线内核呢?
 
等下,我们用的是 Loongnix 的内核,好像还是 3.10.84 版本,这个版本根本就不该有 getrandom,龙芯团队的内核补丁水平我们也是知道的……果然!
 
按照一般的商业逻辑还原一下场景,应该是龙芯的某个客户一定要使用 getrandom 系统调用,龙芯团队就给他加上了;但按照 Loongnix 代码库提交历史,能感受到龙芯的研发团队从来都是能少一事则少一事,客户想要啥,给啥就好了,否则怕影响别的地方,毕竟都没时间精力测试……于是不光漏掉了 32 位内核的对应修改,而且应该是忘了改 glibc,因为直到 glibc 2.25 这个函数才被支持……最终加上 Gentoo 的 user-space,获得了一个四不像!
 
虽然两个地方对我都没影响,问题应该也不在龙芯团队头上,但怎么说都是有些蛋疼的感觉……看起来确乎有必要自己编译内核了 :joy:
 
另外也希望 Loongnix 尽量把自己的代码 upstream 吧,这样反而维护的人手能相当于多一些,况且 arch/mips 等等相关位置的改动所有人都看着,也不需要担心失去控制之类的。实际上,本人一直不是很理解为何一定要坚持自己维护单一一个版本,这主要是因为:
反正据本人了解,许多商业项目(以及龙芯公众可见的所有项目)都是 fork 一份代码出来,然后永远不管,就算提交到上游的代码被别人再怎么改,也不可能影响到项目;维护单一一个版本造成研发人员思维僵化,永远不需要学习新版本的改动。短期来看可能省出了许多时间,但按照上述的“商业逻辑”,下一期项目一切从头评估,上游项目的版本往前推进了许多,这时候跟还是不跟?跟,所有更新版本的学习成本堆积在一起;不跟,最终系统的性能指标、安全漏洞最多跟以往一样,还不如从一开始就连二期都不做。upstreaming 短期来看也有许多成本,尤其像 Linux 这种协作流程有些奇葩的项目,加上龙芯的研发人员英语可能存在沟通障碍(看过 commit message 的人都懂,有些看得我尴尬癌都犯了,最关键最后还没看懂,连作者想说什么汉语都不知道……),upstreaming 可能受到阻碍。但是,这种成本很大程度上是一次性的,每个人只需要付出一遍,在整个几年甚至十几年的职业生涯中显得微乎其微。
 
说到这里,与国际社区的互动是确实有必要的。MIPS 生态本就式微,但仍然有一定体量。不能因为片面追求“全自主”就摈弃一切外界影响,何况由于上述的语言问题,龙芯的社区与国际社区存在信息不对称的现象。MIPS64r6、microMIPS 不支持就算了,自主指令集扩展文档不开放也就算了,GCC/LLVM 支持近乎为零也就算了,各种带汇编加塞儿的软件没有 MIPS/LoongISA 支持也就算了;目前龙芯生态系统建设中,危险的地方在于,国内有 push MIPS/Linux 生态的诉求,但国外的 MIPS 玩家根本感受不到。这使得外界的 MIPS 生态有崩塌的危险,万一发生了,我不认为当前只会 GNU/Linux 或者 Android 换个壳子的所谓“国产系统”能持续性地抵挡住外边的版本升级洪流而不掉队。(除非他们真的跟万年 XP 党一样,能够同一个系统永远不更新,一直用到死。现在看来,这种人还不少。)
 
何况还有各种带颜色的媒体报道,把单纯的建立独立于 Wintel 的另一极计算生态系统的想法无限政治化,殊不知使天下摆脱 Windows/Intel 垄断这件事如果能做成,这件事的意义中最不起眼的恰恰是政治意义!技术上的充分竞争促使商业上也充分竞争;大部分软件都一定要考虑跨平台互操作,对软件行业的良性发展有好处,甚至在未来可能发生下一次架构大迁徙之时,我们能够提前做好准备。至于政治上的自主可控,那不过是做了正确的事情之后,自然会具有的性质。所有国家都有权利建设自主的基础设施,当然也包括计算;因为我们是中国人,发出的声音自然是中国要做自己的 CPU,本身在当前美国本位的 IT 行业,你存在这件事情本身就是(他们的)政治化了,你在长大之前根本无法改变这个事实,只能在媒体报道中无限弱化它,让所有人都淡忘政治性的存在,直到终于成长起来,这时候再说什么都不迟。可惜的是现在国内一提龙芯就是自主可控,甚至还有一部分汉语编程党混进来,根本不提商业上打破垄断有多么深远的意义,宣传上不清楚还有什么好牌可以打了。
 
当然这些东西,我们作为社区开发者,也只能够描述一下见闻和思考;In the meantime,我还是去移植内核补丁了。这个 expat 编译错误以及调试它耗费的时间,最终我选择放弃这个 Loongnix 项目交付的产品;背后的东西,表明很多时候就算你做了很多事情,觉得自己很努力了,但实际上并一文不值。你要用正确的方式做事情才可以。
 
与君共勉。 查看全部
本人在前一阵子团购的 3A3000 开发板上安装了 Gentoo 系统。但由于一直没有时间移植个人所用的 Linux 补丁,一直用 Loongnix 的 linux-3.10.84 临时顶上内核的位置。一开始用 amd64 机器交叉编译的方式自举了整个基本系统,为了简单起见,没有打开 multilib 支持;在 3A3000 上成功引导之后,再打开了 multilib,安装其他软件,整个过程还算顺利。
 
然而在 10 月份后续更新系统的过程中,马上发现 expat 库永远编译不过,安装过程报 expat_config.h header checksum mismatch,意思是这个文件在不同的 multilib ABI 下内容不一致。但有意思的是,无论是 expat 上游还是 Gentoo 社区都完全找不到这个 bug!当时因为工作比较忙,于是没有深究了。
 
最近虽然工作愈发地忙起来了,但正好想搭建一个 Linux 的本地测试环境,公司的后端又用的 Golang,所以想着放在脚旁边的龙芯很适合。于是 expat 这个库挡住了很多软件的编译,我又不想 pin 住它的版本,所以开始继续研究了。
 
两个文件的差异是这样的:
--- ./expat-2.2.5-abi_mips_o32.o32/expat_config.h       2017-11-10 16:07:07.241011603 +0800
+++ ./expat-2.2.5-abi_mips_n64.n64/expat_config.h 2017-11-10 16:07:40.819296062 +0800
@@ -23,7 +23,7 @@
#define HAVE_GETPAGESIZE 1

/* Define to 1 if you have the `getrandom' function. */
-/* #undef HAVE_GETRANDOM */
+#define HAVE_GETRANDOM 1

/* Define to 1 if you have the <inttypes.h> header file. */
#define HAVE_INTTYPES_H 1
@@ -53,7 +53,7 @@
#define HAVE_STRING_H 1

/* Define to 1 if you have `syscall' and `SYS_getrandom'. */
-#define HAVE_SYSCALL_GETRANDOM 1
+/* #undef HAVE_SYSCALL_GETRANDOM */

/* Define to 1 if you have the <sys/param.h> header file. */
#define HAVE_SYS_PARAM_H 1





这是什么情况? o32 ABI 下没有 getrandom 函数,但 n64 下却有?(看了 configure.ac 文件,上边的判断为假才会检测下边那个不一致对应的选项,所以相当于只有一处不一致。)连单个架构下 ABI 都不能保持一致的 syscall 实现,这种代码怎么可能逃过 Linux 各大子系统 maintainers 的法眼,而进入主线内核呢?
 
等下,我们用的是 Loongnix 的内核,好像还是 3.10.84 版本,这个版本根本就不该有 getrandom,龙芯团队的内核补丁水平我们也是知道的……果然
 
按照一般的商业逻辑还原一下场景,应该是龙芯的某个客户一定要使用 getrandom 系统调用,龙芯团队就给他加上了;但按照 Loongnix 代码库提交历史,能感受到龙芯的研发团队从来都是能少一事则少一事,客户想要啥,给啥就好了,否则怕影响别的地方,毕竟都没时间精力测试……于是不光漏掉了 32 位内核的对应修改,而且应该是忘了改 glibc,因为直到 glibc 2.25 这个函数才被支持……最终加上 Gentoo 的 user-space,获得了一个四不像!
 
虽然两个地方对我都没影响,问题应该也不在龙芯团队头上,但怎么说都是有些蛋疼的感觉……看起来确乎有必要自己编译内核了 :joy:
 
另外也希望 Loongnix 尽量把自己的代码 upstream 吧,这样反而维护的人手能相当于多一些,况且 arch/mips 等等相关位置的改动所有人都看着,也不需要担心失去控制之类的。实际上,本人一直不是很理解为何一定要坚持自己维护单一一个版本,这主要是因为:
  1. 反正据本人了解,许多商业项目(以及龙芯公众可见的所有项目)都是 fork 一份代码出来,然后永远不管,就算提交到上游的代码被别人再怎么改,也不可能影响到项目;
  2. 维护单一一个版本造成研发人员思维僵化,永远不需要学习新版本的改动。短期来看可能省出了许多时间,但按照上述的“商业逻辑”,下一期项目一切从头评估,上游项目的版本往前推进了许多,这时候跟还是不跟?跟,所有更新版本的学习成本堆积在一起;不跟,最终系统的性能指标、安全漏洞最多跟以往一样,还不如从一开始就连二期都不做。
  3. upstreaming 短期来看也有许多成本,尤其像 Linux 这种协作流程有些奇葩的项目,加上龙芯的研发人员英语可能存在沟通障碍(看过 commit message 的人都懂,有些看得我尴尬癌都犯了,最关键最后还没看懂,连作者想说什么汉语都不知道……),upstreaming 可能受到阻碍。但是,这种成本很大程度上是一次性的,每个人只需要付出一遍,在整个几年甚至十几年的职业生涯中显得微乎其微。

 
说到这里,与国际社区的互动是确实有必要的。MIPS 生态本就式微,但仍然有一定体量。不能因为片面追求“全自主”就摈弃一切外界影响,何况由于上述的语言问题,龙芯的社区与国际社区存在信息不对称的现象。MIPS64r6、microMIPS 不支持就算了,自主指令集扩展文档不开放也就算了,GCC/LLVM 支持近乎为零也就算了,各种带汇编加塞儿的软件没有 MIPS/LoongISA 支持也就算了;目前龙芯生态系统建设中,危险的地方在于,国内有 push MIPS/Linux 生态的诉求,但国外的 MIPS 玩家根本感受不到。这使得外界的 MIPS 生态有崩塌的危险,万一发生了,我不认为当前只会 GNU/Linux 或者 Android 换个壳子的所谓“国产系统”能持续性地抵挡住外边的版本升级洪流而不掉队。(除非他们真的跟万年 XP 党一样,能够同一个系统永远不更新,一直用到死。现在看来,这种人还不少。)
 
何况还有各种带颜色的媒体报道,把单纯的建立独立于 Wintel 的另一极计算生态系统的想法无限政治化,殊不知使天下摆脱 Windows/Intel 垄断这件事如果能做成,这件事的意义中最不起眼的恰恰是政治意义!技术上的充分竞争促使商业上也充分竞争;大部分软件都一定要考虑跨平台互操作,对软件行业的良性发展有好处,甚至在未来可能发生下一次架构大迁徙之时,我们能够提前做好准备。至于政治上的自主可控,那不过是做了正确的事情之后,自然会具有的性质。所有国家都有权利建设自主的基础设施,当然也包括计算;因为我们是中国人,发出的声音自然是中国要做自己的 CPU,本身在当前美国本位的 IT 行业,你存在这件事情本身就是(他们的)政治化了,你在长大之前根本无法改变这个事实,只能在媒体报道中无限弱化它,让所有人都淡忘政治性的存在,直到终于成长起来,这时候再说什么都不迟。可惜的是现在国内一提龙芯就是自主可控,甚至还有一部分汉语编程党混进来,根本不提商业上打破垄断有多么深远的意义,宣传上不清楚还有什么好牌可以打了。
 
当然这些东西,我们作为社区开发者,也只能够描述一下见闻和思考;In the meantime,我还是去移植内核补丁了。这个 expat 编译错误以及调试它耗费的时间,最终我选择放弃这个 Loongnix 项目交付的产品;背后的东西,表明很多时候就算你做了很多事情,觉得自己很努力了,但实际上并一文不值。你要用正确的方式做事情才可以。
 
与君共勉。

R7 350独立显卡 pmon花屏啊,这个有什么解决办法吗

zhuchen 回复了问题 • 3 人关注 • 2 个回复 • 159 次浏览 • 2017-11-08 16:57 • 来自相关话题

龙芯版的thundbird支持GnuPG加解密插件吗?

wanghonghu 回复了问题 • 2 人关注 • 3 个回复 • 167 次浏览 • 2017-11-08 16:41 • 来自相关话题

按照官方文档编译内核失败

iapcmloongson 回复了问题 • 3 人关注 • 4 个回复 • 334 次浏览 • 2017-11-07 21:14 • 来自相关话题