still some gotchas in the PID provider (certain instruction emulation
issues). As fast as I can fix them, people are raising new issues.
Supporting older kernels is very labor intensive - I make slow
forwards progress, but each forward step raises issues with the
legacy kernels. The recent taskq work (which uses Linux workqueues) is
a good case in point.
The taskq code is very simple - a mechanism for running background
tasks away from a user process - to avoid interrupt deadlock.
But those few lines of code rely on a mechanism which has many radical
changes in the kernel.
The workqueue API is a mixture of #defines and real functions.
Many of the functions are GPL functions. So, it works on kernel N, but
not kernel N-1. Its quite time consuming ensuring that the 'fix' I
put in for kernel N, doesnt affect kernel I, J, K, L, M, etc.
Then people report issues on kernels I dont have. Just had a report
of issues on Centos 6.3. In fact in recent days, I have got
Centos 5.2, 5.3, 5.5, 5.6 and 6.3 running in VMs (getting quite adept
at configuring from scratch). The Centos/RedHat kernels have
confusing kernel version numbering because one cannot rely on the
triplet versioning (2.6.32, for instance) to determine which kernel
we are compiling under.
Anyway, the quote of the day is attributed to Jeffrey:
You are brought this tool to the Common Man and not the guy who has a
Thank you Jeffrey for that. Despite him having some strange issues on
Centos 6.3, it feels worthwhile just for that, alone.
Now, off to strip the PID provider bare. If I win, I'll report back.
If not, I got sucked into a VM, and couldnt find the exit.