One possible utterly non-standard concept I've been toying with:
Asynchronous/Repeatable "slates" of system calls.
This would allow the following:
1) Setting some kernel/lib feature to tape-record all syscalls
(or syscalls of various types) with all the live addresses and
arguments kept intact (careful regarding stack variables!).
(Probably even executing them as called.. but recording them too).
The sequence of calls made is then considered to be on a "slate."
with some system-global or process-indexed ID number (maybe used
via a /dev/file mapping?).
2) Then, any time desired the whole slate of calls can be invoked and
any non-zero returns can be delivered via signal or placed in a user
buffer and a flag set. They could be operated on in order or in
parallel. The single "run-slate()" call returns upon the slate's
complete execution in kernelspace.
This would allow very high speed operations of devices that require a
sequence of system calls and/or ioctls that have to enter kernel
space. It would allow complex manipulations to be much more reliable.
Since user memory is still active, one could change user memory and
then re-run the slate again and again with the varied parameters.
If one wanted to get *really* fancy, various guards could be set for each
system call, preventing some from running but allowing others.
It would also provide a useful means of encapsulating *any* asynchronous
interface in the kernel. If a system call could require a
"start/done_yet" pair of calls (the second is for polling completion)
and you have 18 of them.... Great! Just make a "slate" that is
composed of all the various "done_yet()" calls, as well as a slate of all the
"start" calls. Launch the starts in "parallel" and receive a
"not-done-yet" status from every one that isn't done. Keep polling the
slate until all of those needed return "success". (This could allow
partial recovery when a few have succeeded but the rest are still pending).
(This could also allow more incredibly lightweight polling calls to
be implemented because they'd suddenly become practical.. in large numbers).
The whole deal could remain compatible with other platforms too. "Record"
the same slate of done_yet calls (i.e. without real recording support) as a
poll and then use that as the "slow" version of the Linux
asynchronous-replay feature.
Note here:
- no new kernel threads are needed, because its merely a lonnnng "composed"
system call
- no user/group permissions are a problem
- nothing more than the same load problems that already exist could happen
(unless the slate was too big for a single ctxt-switch)
Its just a high performance and async-polling hack, but for Gamez or for really
zippy stuff, I cannot see missing out on composing such nifty kernelspace
benefits. The amount of time saved for some device controller, sound, for
some high speed graphics, a complex configuration sequence, or for
quick and repetative mass-slorping of information,.. the benefit could be
substantial.
- Christopher H.