Following the the recent discussion in the logs, and reports by lobbes and spyked, time has come for me to publish a work plan as well.
I would divide all tasks into two groups: larger TODO items that I find important but that may take unpredictable amount of time, and smaller items work, on which someone else is perhaps working already.
The larger items are the following:
1. Adapt assembly FFA code to at least Chapter 14B1. After that, if the performance improvement is significant enough, I can switch to reading rest of FFA in leisure mode. There was also an idea of making a speed monster asm-only FFA variant2. I have to admit that without a concrete and pressing use-case, I'd be hesitant to take up this project - it does not seem worthwhile spending time polishing assembly if the expected returns are 0.5% performance improvement in a rarely used command. Nevertheless, I find that speed gains for modexp code would be a welcome addition to FFA. Also, I put this item first because I really don't like to work on several things at once, even if it is inevitable sometimes.
2. Ripping out kernel RNG as mentioned several times in the logs. This would involve some amount of investigative work at the beginning, that should take totally predictable amounts of time3. Then, come up with a plan to provide raw random bits to kernel from FG. The standard way of doing this4 comes in contrary to the "buffered RNG is not useful RNG" rule from the logs, so some way that avoids buffering must be found.
3. Some GNAT work, given that ave1 is busy with ARM64 SJLJ runtime. There is a bug with the variable finalization in static libraries reported by asciilifeform. Also, per my reading of GNAT runtime source, it might be possible to have asynchronous thread aborts with ZCX as well, with a small amount of code changes and slightly increased code smell - this would be something to have a look at as well5.
There also are some items that may be nice to work on, but are either not a priority right now, or have someone working on them already:
- For vtools, I have a candidate fix for the vdiff issue with large files6, and a small usability improvement for ksum - handling input from stdin.
- Writeup about the firefly board, how to make it more or less usable, and why it may be not worth spending time on this board at all.
- Another item in my TODO was avoiding gcc5 step in the cuntoo build process. When ave1gnat gets added to cuntoo, this step will be immediately eliminated, so I guess the correct way to approach this is provide help to mod6 if he need any.
- Testing the cuntoo-based TRB rotor (made by mod6) on ARM64. Some basic testing showed the the configure scripts of the dependencies (bdb, openssl) do not support aarch64, which will most likely cause a rewrite to a saner build system.
There are other items fluctuating in the logs, like TMSR ECC code for TRB, but I guess it's too early to put them into my TODO list.
The timeline for the work would be something like following:
- FFA work should take around two weeks - starting 02.07.2019 (so until around 16.07.2019) - to work through the next chapters, including the mathematical proof in Chapter 14. The assembly code is unlikely to change, but there is always a requirement to do measurements, investigate where bottlenecks are, see if something else really calls for asming, if yes - amend plans accordingly.
- After that, I would be open to work on any of the items 2 or 3, as the forum sees fit. So far I haven't seen any pressing need for item 2, thus there is a question whether working on ave1gnat could be a priority direction, or should be left fully for ave1.
Comments are welcome.
- OK, at least this should take predictable amount of time. [↩]
- If only I could find the log reference... [↩]
- Two, at most three weeks as far I can see now. [↩]
- A ring buffer fed by a userspace process that may read bits from a FG or two, pass zeros or any other known sequence, and generally speaking be under user's control. [↩]
- Unless ZCX is fully proscribed, of course. [↩]
- Basically, I adapted ksum code to hash a file chunk-by-chunk. [↩]