Implicit Local Virtual Devices

"I.V.s"

In unix a process is born with a parent, the ownership characteristics and permissions of the parent, and three pre-opened file IO channels. Dos imitates the three channels between tasks, not processes. The three channels basically models a process as a user at a teletype, which made perfect sense for a multi-user OS in 1974. That's all a unix process gets implicitly. The basic IO channels are also handy for using processes in coordination with each other on single tasks. A computer doesn't need IO to technically be a computer, but it does need some kind of IO to be useful.

Ha3sm implicits are very different. IO is channels to and from devices, not files. Access control is per-channel, which may be an entire disk-drive, for example, but only one way per channel. Using several processes on one task is theoretically good for program factoring, but is bad for realtime considerations and system simplicity. Process coordination leads to signals and other tricky system services. IF unix needs a realtime facility, or a low-level facility, it is outside the basic unix paradigm, and/or slow. Giving each process some implicit facilities tends to make processes bigger, but less numerous, with simpler inter-process issues.

A Ha3sm process will have several implicit local devices in the process's memory space. They will look like memmapped hardware ports to the process. To illustrate the rationale for this, consider a timer. Timers are almost as useful to a computer as the CPU, and so it is with processes.

When a Ha3sm process is created the user will request an implicit's location or be assigned the default. As the system and the new process then run asynchronously, the system will write the necessary data to those virtual devices on it's timescale. One of those devices, at some known location in the virtual port space, will be a timer. The timer will be an uptime count for the process, up-counted at some known period by the system. That is, a memory location in process memoryspace will be incremented periodically on the timescale of the system. This will probably be run off the sub-second timer of the PC "CMOS clock", at e.g. 8 (binary) Kilohertz.

A process is thereby provided with a reasonably useable real world timescale, implicitly, via a simple intra-process memory location read. The burden on the system increases straight-line per-process for such a device, but the overhead for each device is just a very few instructions, particularly if all processes' timers get updated in a batch. All timers can be updated in a single pass off, say, the CMOS subsecond interrupt, without per-process process-switch or system-user border issues per timer. A timer, also, is one of the higher periodicity devices contemplated. Others may need to be updated much less often.

So now we have a very useful bit of info implicit to any process; it's lifetime so far in realworld time ticks. A process can use this info to handle IO timeouts on it's own, for example. This places the burden for that on and in the process itself, rather than on the system. That's good design. Things that use resources should pay for them, so the cost of timeout code should be on the process needing that facility. Even better, the system doesn't need to handle IO timeouts, which leads to other complexities like signals. Thus an information service like a timer running implicitly keeps things much simpler. The code hit for updating the timers pays off in spades in system simplicity.

Ha3sm strives to not give info a process doesn't need. This has to be watched very carefully with implicits. A real timer allows a process to determine, very vaguely, how much of the CPU it is using, for example. That sort of thing is acceptable for the complexity avoided. A process can't know if the rest of the CPU use is code or "the halt process".

What are some other things that have a good complexity savings aspect as implicit local virtual devices? Unix virtual /dev/ devices are suggestive. A random number generator, or perhaps just a seed, comes to mind. A multimedia OS might also do well to inform all processes about the crucial info of the current "performance". There can be a system provided keynote, meter, tempo, color key, a sync timer value for "the one" of the meter, and so on. Things in a system doing music and so on are probably not opposed to sharing such info. Such info as current key will not change often enough to noticeably load the system either.

A date/time might as well be provided to everybody at init time, combined with a "churchbell" at midnight. That info plus the timer gives a timestamp without a request (syscall), implicitly, locally.

The basic features of a candidate for an IV are, it's a simple write from the system to the process, it's not informative about other processes, it isn't a huge computational burden, and so on. Positively, it should enhance system simplicity. Timers are a huge win. To be a candidate for a Ha3sm standard IV, it should also be platform-neutral.

Channel list

Some systems implement detailed access control lists for each file. This is ponderous. Somewhat analagously, each Ha3sm user has a channels list. That list will be implicit to any process run by that user, but will be enforced by the "please" syscall, and will not be so implicit as to be present in the memory-space of such a process. After the appropriate "please", stream channels will asynchronously appear to be running implicitly local to the process, via changes to the related local ring buffer. Block transfers will always require a system request.

Optionals

Then we get into things that are nice for a process to have, but might best be something they have to request at init time due to resource consumption or other issues. A Minix/Linux virtual terminal perhaps. A Forth-like blocks service to some default storage device perhaps.