Status

The KISS Realtime Kernel has been a part-time development effort since late 1996. I'd rather spare you the detailed history. Two prototypes have been implemented. First, they ran under SDS's SingleStep 68K debugger/simulator. A crippled version used to be available here. Then under Microtec's XRAY 68K debugger/simulator. No free version of XRAY is available at this time. Documentation for KISS is now available.

The source code will not be released until one of two things happen:

The developer of a debugger/simulator will make a free (crippled) demo version available, which provides simulated timer, input and output.
A publisher accepts the book for publication, and sends it off to the printers.

Frankly, it would be pointless to release this kernel without one of these two events happening.

Desired Feedback

At this time, feedback is requested on the KISS Application Programming Interface. Please concentrate on the following items:

Data Types
Signals
Messages
Device Drivers

Data Types

Are the selected data types the most appropriate, or would more generic data types be better. Take a look at section 3.1 of the User's Manual. Are the data types suggested in dark red preferable?

The advantage of the current long list of data types is that individual functions' parameters can be tailored. These provide the best possible implementation efficiency and the most portability. The explicit data types also make it easier to figure out what a variable represents. QueueType foo is more explicit than ObjectType bar. However, this list of datatypes is long, and may causes novices to take longer to get familiar with the kernel.

The advantage of the short list in dark red is simplicity. Novices will take less time to learn how to program with KISS. On the other hand, limiting masks, interrupt sizes, options and error to the long data type prevents future expansion. Current 8-bit and 16-bit implementations might also find the long data type to be too large.

Signals

Signals are an effective synchronization mechanism and are used internally by the KISS kernel for semaphroes, messages, timers, and so on. Signals are traditionally available in all small realtime kernels. On the other hand, applications running in memory protected kernels prefer using semaphores and messages exclusively. Should signals only be available to supervisor tasks in a memory protected kernel?

The advantages of limiting signals to supervisor tasks only is that no extensive parameter checking/decoding needs to be performed. This makes signals faster. Memory protected user tasks might find it preferable to use only semaphores and message passing for communication anyway.

The disadvantage is that even user tasks might enjoy the extended functionality of signals. An application written for a K8 kernel might want to be ported to a K32 implementation without having to set all tasks as supervisor tasks.

Messages

Some modern operating systems allow messages to be chained, or attached. That is, a message can be made larger, not by copying its data to a large buffer, but by linking buffers together. The idea is that, for example, if you are reading a file from an ethernet network, and are writing the data to disk, then you can simply attach link the multiple segments received over the network and send them to the disk driver as one message.

Should the KISS kernel have an AttachMessage() function that provides this functionality?

Device Drivers

What kind of interface sould be provided to device drivers? Three options are available:

A file system interface
A message queue interface
A direct [address,length] interface

Should KISS provide a file system interface to device drivers, like Unix does? Obviously it can be very beneficial to have a common file system interface available so that applications can write to files, devices or networks in an orthogonal way. But in that case, at what level should the file system interface be offered? At the file system level!

At some level, there still needs to be a low-level interface where an exact address and length are specified. This is why the currently defined interface is a physical interface.

A message queue interface would also be specifying address and length parameters, with the added advantage that no new system calls would be needed. An application would write to one queue to output data, and read from a different queue to receive data. If messages can be chained, these operations are speeded up more, though at some cost to device driver and application complexity.