I have a choice of projects to select next. Having
recently fixed a tidy sum of bugs in CRiSP and fixed a few
long standing issues/niggles of mine (xxx.yyy++ anyone?!)
I need to get the next projects off the ground.
Heres the options.
UTF-8 in CRiSP. CRiSP supports UTF-8 but strangely its not
as natural as I would like/expect. Things are complicated
because multiple things need to be supported (cursor parsing
and treating UTF-8 as single chars, display, display in char mode,
X11, Windows and MacOS). I need to work out how it currently works
or does not work and go fix.
DTrace. Yes, its time to get back on this hobby horse. Theres
two immediate avenues of research -- the PID provider - figure out
what is breaking in the user space; and the other is ARM support. Now I
have a RaspberryPi, there are a few challenges ahead.
I'll briefly summarise what needs to be done to the code for ARM.
Initially the goal is to just target the RPI - I dont have enough
ARM devices to toy with, so it sets a baseline.
Firstly, we need an instruction decoder for ARM. The one
for the Intel instruction set, mostly courtesy of Sun, is obviously
useless for ARM. If I am lucky, the instruction decoder is simple
for ARM, since all instructions are 32-bit (are they?)
Next, much of the code assumes we are i386 or amd64, and thats no
longer true; so, even compiling as ARM is going to require various
cleanups and tweaks.
Lastly, building on the RPI itself is going to require one
or more kernels. At least I need the kernel sources, but it
may well be that I need to cross-compile - the 256MB RAM may be
too low for dtrace to compile - I hope not.
But the last stumbling issue is 256MB of RAM is very puny. I think
the smallest VM i have tried is 384MB of RAM. Although dtrace isnt
very big, it can use quite a chunk of memory for per-cpu data
structures, and this could leave too little for the rest of the system
to work. So, I may need to turn off the instr provider and try and
be very feeble in memory requirements.