Comments on: TMSR OS, February 2020 Statement http://dorion-mode.com/2020/03/tmsr-os-february-2020-statement/ From the abyss, life. From silence, music. Wed, 15 Apr 2026 10:01:10 +0000 http://polimedia.us hourly 1 By: Robinson Dorion http://dorion-mode.com/2020/03/tmsr-os-february-2020-statement/#comment-128 Robinson Dorion Mon, 09 Mar 2020 18:08:21 +0000 http://dorion-mode.com/?p=700#comment-128 <strong>@bvt</strong> : <blockquote> 2.6.32 (not 2.16, btw) </blockquote> Thanks, fixed. <blockquote> While v.sh seems to work through this mess rather fast ... So, so far I am inclined to abandon 4.9 tree and start anew from 2.6.32 genesis. </blockquote> Good to hear on the speed at least, but I agree with the inclination. <blockquote> anyway we don't want to bring perl to TMSR-OS with the kernel. </blockquote> Agreed. Thanks for the update on the TODOs, sounds good and keep it up! @bvt :

2.6.32 (not 2.16, btw)

Thanks, fixed.

While v.sh seems to work through this mess rather fast ... So, so far I am inclined to abandon 4.9 tree and start anew from 2.6.32 genesis.

Good to hear on the speed at least, but I agree with the inclination.

anyway we don't want to bring perl to TMSR-OS with the kernel.

Agreed. Thanks for the update on the TODOs, sounds good and keep it up!

]]> By: Diana Coman http://dorion-mode.com/2020/03/tmsr-os-february-2020-statement/#comment-126 Diana Coman Sat, 07 Mar 2020 16:05:44 +0000 http://dorion-mode.com/?p=700#comment-126 Was there anything further heard from the rEFInd guy or what did his <a href="http://dorion-mode.com/category/tmsros/?b=Rod&e=#select" rel="nofollow">"positive reply"</a> consist in? Was there anything further heard from the rEFInd guy or what did his "positive reply" consist in?

]]> By: bvt http://dorion-mode.com/2020/03/tmsr-os-february-2020-statement/#comment-125 bvt Thu, 05 Mar 2020 20:39:42 +0000 http://dorion-mode.com/?p=700#comment-125 @Dorion: Current status of 2.6.32 (not 2.16, btw): I have a few trees that I'll have to materialize into vpatches: - 2.6.32.71 genesis. The question to this is should it be proper genesis, or downgrade vpatch from the previous 4.9-genesised kernel. The problem here is that 4.9 genesis is 600 Mb, 2.6.32 genesis is 300 Mb; but the downgrade patch 4.9 to 2.6.32 is 700 Mb. While v.sh seems to work through this mess rather fast (more precisely, flow resolution is fast when compared to pressing to the rest of the process), there is quite some storage space overhead from the downgrade, also vpatching the tree together becomes a bottleneck for the work process. So, so far I am inclined to abandon 4.9 tree and start anew from 2.6.32 genesis. - 2.6.32-add-kfifo. This tree ports 4.9 kfifo and generator for timeconst.h: in 2.6.32 this was computed using a <a href="http://logs.ossasepia.com/log/trilema/2019-02-23#1898922" rel="nofollow">perl script</a>, which does not work with the perl version in Cuntoo, and anyway we don't want to bring perl to TMSR-OS with the kernel. TODO for this tree: testing that new kfifo work with the old code: the functions present in 2.6.32 are the same, so all should be OK. - 2.6.32-add-keccak. Regrind with minor changes of the Keccak vpatch. No problem at all expected here. A tree and vpatch that is still in the TODO is the one that brings the Keccak RNG. I will have to review the API differences between 4.9 and 2.6.32. It seems that 4.9 API is a strict superset of 2.6.32 API, so no problem is expected, but still, more care is needed here. Also, I expect that this weekend I will still be continuing v.sh series as the result of the <a href="http://ossasepia.com/2020/02/29/a-basic-requirement-for-the-literate-introducing-of-new-tools/" rel="nofollow">latest</a> <a href="http://bvt-trace.net/2020/02/vsh-parts-25-and-3-one-binary-ada-solver-and-ada-vfilter-implementation/" rel="nofollow">discussions</a>. @Dorion:
Current status of 2.6.32 (not 2.16, btw): I have a few trees that I'll have to materialize into vpatches:
- 2.6.32.71 genesis. The question to this is should it be proper genesis, or downgrade vpatch from the previous 4.9-genesised kernel. The problem here is that 4.9 genesis is 600 Mb, 2.6.32 genesis is 300 Mb; but the downgrade patch 4.9 to 2.6.32 is 700 Mb. While v.sh seems to work through this mess rather fast (more precisely, flow resolution is fast when compared to pressing to the rest of the process), there is quite some storage space overhead from the downgrade, also vpatching the tree together becomes a bottleneck for the work process. So, so far I am inclined to abandon 4.9 tree and start anew from 2.6.32 genesis.
- 2.6.32-add-kfifo. This tree ports 4.9 kfifo and generator for timeconst.h: in 2.6.32 this was computed using a perl script, which does not work with the perl version in Cuntoo, and anyway we don't want to bring perl to TMSR-OS with the kernel. TODO for this tree: testing that new kfifo work with the old code: the functions present in 2.6.32 are the same, so all should be OK.
- 2.6.32-add-keccak. Regrind with minor changes of the Keccak vpatch. No problem at all expected here.
A tree and vpatch that is still in the TODO is the one that brings the Keccak RNG. I will have to review the API differences between 4.9 and 2.6.32. It seems that 4.9 API is a strict superset of 2.6.32 API, so no problem is expected, but still, more care is needed here.
Also, I expect that this weekend I will still be continuing v.sh series as the result of the latest discussions.

]]>