Comments on: Linux kernel: genesis and early entropy users http://bvt-trace.net/2019/09/linux-kernel-genesis-and-early-entropy-users/ Fri, 21 Aug 2020 17:11:49 +0000 http://polimedia.us hourly 1 By: Implementing TMSR OS « Dorion Mode http://bvt-trace.net/2019/09/linux-kernel-genesis-and-early-entropy-users/#comment-96 Implementing TMSR OS « Dorion Mode Fri, 29 Nov 2019 17:44:25 +0000 http://bvt-trace.net/?p=48#comment-96 [...] Linux 4.9.95 was genesis'd and feeding the RNG with FG is [...] [...] Linux 4.9.95 was genesis'd and feeding the RNG with FG is [...]

]]> By: bvt http://bvt-trace.net/2019/09/linux-kernel-genesis-and-early-entropy-users/#comment-74 bvt Thu, 05 Sep 2019 19:06:51 +0000 http://bvt-trace.net/?p=48#comment-74 I see. Device tree file typically contains the configuration of SoC (voltages, peripherals configuration, where exactly to find ttys, etc), so I assume the platform configuration moved from some header to dbt file? The problem with device files is that for ARM64, supporting many devices without dtbs would be ~impossible, but if in-source support was there before - it's certainly a huge ugh. Re kernel weight, the minimal image for x86_64 qemu produced by the procedure in this post is ~2.2Mb. The minimal kernel for MIPS should be around the same. I see. Device tree file typically contains the configuration of SoC (voltages, peripherals configuration, where exactly to find ttys, etc), so I assume the platform configuration moved from some header to dbt file? The problem with device files is that for ARM64, supporting many devices without dtbs would be ~impossible, but if in-source support was there before - it's certainly a huge ugh.

Re kernel weight, the minimal image for x86_64 qemu produced by the procedure in this post is ~2.2Mb. The minimal kernel for MIPS should be around the same.

]]> By: Stanislav Datskovskiy http://bvt-trace.net/2019/09/linux-kernel-genesis-and-early-entropy-users/#comment-73 Stanislav Datskovskiy Thu, 05 Sep 2019 18:50:30 +0000 http://bvt-trace.net/?p=48#comment-73 > not that the code that does actual work Nope, much of the functionality in device drivers has been moved to "device tree files", and out of the code. > is version 4.9 totally unusable for MIPS Theoretically usable, but would have to rewrite entirely. And was reluctant to pick the considerably heavier kernel. > not that the code that does actual work

Nope, much of the functionality in device drivers has been moved to "device tree files", and out of the code.

> is version 4.9 totally unusable for MIPS

Theoretically usable, but would have to rewrite entirely. And was reluctant to pick the considerably heavier kernel.

]]> By: bvt http://bvt-trace.net/2019/09/linux-kernel-genesis-and-early-entropy-users/#comment-72 bvt Thu, 05 Sep 2019 18:28:26 +0000 http://bvt-trace.net/?p=48#comment-72 Indeed, in the future supporting multiple versions of kernel may become a necessity due to architecture requirements; however I'd like to keep the 'zoo' of actively used versions as small as possible. Re. 3.x-4.x diff - I expect that it is huge, but I'd also bet that it's rewritten is a sense of function names/APIs changed, not that the code that does actual work (I wonder what percentage of kernel LoC falls into this category?) is different. Which leads to the following question: is version 4.9 totally unusable for MIPS due to some fundamental breakage? Or is it just the version you (or IIRC original image provider?) picked, and moving that kernel to version 4.9 is still possible? Indeed, in the future supporting multiple versions of kernel may become a necessity due to architecture requirements; however I'd like to keep the 'zoo' of actively used versions as small as possible.

Re. 3.x-4.x diff - I expect that it is huge, but I'd also bet that it's rewritten is a sense of function names/APIs changed, not that the code that does actual work (I wonder what percentage of kernel LoC falls into this category?) is different.

Which leads to the following question: is version 4.9 totally unusable for MIPS due to some fundamental breakage? Or is it just the version you (or IIRC original image provider?) picked, and moving that kernel to version 4.9 is still possible?

]]> By: Stanislav Datskovskiy http://bvt-trace.net/2019/09/linux-kernel-genesis-and-early-entropy-users/#comment-71 Stanislav Datskovskiy Wed, 04 Sep 2019 18:50:48 +0000 http://bvt-trace.net/?p=48#comment-71 > In case there is a necessity to move to older kernel, this can always be achieved by providing a corresponding vpatch. I found myself stuck on this. My "M" kernel is written for 3.x, whereas RK requires 4.x; the latter includes the "device tree" gnarl (and much else, just about *all* iron-related code was rewritten) and consequently the diff distance b/w a 3.x and 4.x is gargantuan. > In case there is a necessity to move to older kernel, this can always be achieved by providing a corresponding vpatch.

I found myself stuck on this. My "M" kernel is written for 3.x, whereas RK requires 4.x; the latter includes the "device tree" gnarl (and much else, just about *all* iron-related code was rewritten) and consequently the diff distance b/w a 3.x and 4.x is gargantuan.

]]> By: bvt http://bvt-trace.net/2019/09/linux-kernel-genesis-and-early-entropy-users/#comment-70 bvt Wed, 04 Sep 2019 16:35:59 +0000 http://bvt-trace.net/?p=48#comment-70 The binary documentation files are non-SVG images and PDFs - fits description of "binary documentation" perfectly. The binary documentation files are non-SVG images and PDFs - fits description of "binary documentation" perfectly.

]]> By: PeterL http://bvt-trace.net/2019/09/linux-kernel-genesis-and-early-entropy-users/#comment-69 PeterL Wed, 04 Sep 2019 12:39:01 +0000 http://bvt-trace.net/?p=48#comment-69 "However, someone very bright decided to add binary documentation files to the Linux repository, so now I have to provide them separately:" Maybe I am missing something here, but why would the documentation, which is specifically meant to be read by humans, be included as binary instead of text? "However, someone very bright decided to add binary documentation files to the Linux repository, so now I have to provide them separately:"

Maybe I am missing something here, but why would the documentation, which is specifically meant to be read by humans, be included as binary instead of text?

]]>