Messages in this thread |  | | From | (Christopher Hassell) | Subject | Re: 2.2.0 wishlist | Date | Thu, 13 Jun 1996 14:29:49 -0600 (MDT) |
| |
Wild idea test....
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.
|  |