About KISS Home |
FAQ1. When do you plan to release the source code? 2. What processor/boards does KISS run on? 3. Why did you chose a new interface, why not pick an existing API standard? 4. Why should I use the KISS kernel and not realtime Linux?
1. When do you plan to release the source code?The KISS kernel was initially meant as an example accompanying the book The Design and Implementation of Realtime Kernels. Given that the source code is still in the prototype stage, I feel that it is not sufficiently readable by itself without the benefit of the book's insight and explanations. Basically, I wish to supply a kernel which is useful, not just a pile of code to stare at. As soon as a publisher of source-level debuggers/simulators makes a crippled version available free for download, including interrupt based simulated I/O and timers, I will integrate the kernel and test suite with the debugger, even if the book is not printed yet, as that would be useful enough to tinker with.
2. What processors/boards does KISS run on?At this time, I ported KISS only to the 68K architecture, without FPU support, such as the 68010 and CPU32 series of processors. Initially, I wrote a device driver for the simulated timer on the SDS SingleStep simulator. Currently, the kernel runs under Microtec's VRTX simulator, with device drivers for simulator timers and output window. I have asked both Microtec and SDS for a free crippled version of their debuggers with simulated I/O, and have been met with loud silence. The very first kernel was also integrated with the VRTX debugger, offering displays of lists of tasks, semaphores, queues, messages, etc., but the old version of the debugger I had did not allow symbol variable printing, and as soon as I split the old kernel into two version, all the macros I wrote failed.
3. Why did you chose a new interface, why not pick an existing API standard?The available choice of interfaces was rather abysmal. Basically, I had TRON, Posix, OSEK and Win32 to choose from. Even today, I still agonize over my decision to develop a new one, which is thankfully very similar to the VRTX, pSOS, Amiga and Win32 interfaces. I realize very well the advantages of adopting an existing interface. In particular, choosing TRON would have Japanese companies showering me with offers of support and juicy contracts, and adopting OSEK would have German companies offering me free beers and bimmers. Mostly beers. The ideal characteristics of a kernel interface are:
The KISS kernel interface consists of 55 system calls, of which 25 are Open/Close/Create/Delete calls. The names of the functions are blatantly obvious, and so are the parameters required. The interface supports the implementation of memory protection, multiprocessing, efficient copy-less message passing and waiting on multiple kernel objects. The TRON interface was not adopted mostly due to its heaviness. The iTRON interface specifies about 96 function calls, some of which are clearly redundant, such as GetTask() and GetSelfTask(). The interface does not support waiting on multiple kernel objects, and the TRON standard has never really caught on in the West. Cygnus' ecos supports the iTRON interface though. The standard is tightly controlled by Prof. Ken Nakamura of Tokyo University. The POSIX interface encompasses several different standards. The first one is the UNIX system call interface as available in V7. Later came the Posix calls, adding not only new functionality, but also a new interface style. Think of the message queue calls, such as mq_open() and mq_getattr(), requiring parameters of the type mqd_t and mq_attr. If a programmer wishes to write an application requiring tasks to both share address spaces and run in separate address spaces, he has to use two distinct programming interfaces. Posix differentiates substantially between system calls applying to threads and processes. Essentially two operating system interfaces are defined, those applying to tasks running in the same address space, and those applying to tasks running in separate address spaces. The system calls are very similar in those two interfaces, but they are not indentical. The Win32 interface is fairly clean and complete, and allows waiting on multiple kernel objects. It also has the benefit of having millions of programmers famialiar with it. Win32 programmers are a dime a dozen, thought the learning curve for programming embedded systems and using the tools is much steeper than the learning curve for learning a new kernel interface. Unfortunately, the Win32 interface is at times imprecise, and the company controlling it is known to intentionally modify unsuspected behavior in order to obtain an advantage. Given that the standard is not open, and the company controlling it is untrustworthy, this interface cannot be chosen. The OSEK interface is clean and does not impose any new abstractions. It is supposedly complete and open, but not quite. OSEK lacks dynamic object creation routines, the ability to wait on multiple objects, and a message passing paradigm allowing the transfer of message ownership. Perhaps I could have adopted the OSEK standard for the functions that fulfill my requirements, and simply added the extentions that I need. Unfortunately, those API extentions may not be in accord with the ruling body's future plans. And unfortunately, the ruling body is not open to outsiders, but rather formed of the member companies' representatives. For example, in the fall of 1999, Ken Tindell, a veteran realtime kernel expert, while working on an OSEK kernel implementation of his own, came up with several concerns about the interface, which he publicly itemized, and which he believed made OSEK unsuitable for immediate deployment. The response of OSEK was to claim that his concerns were already known, that solutions existed, and that they would work privately with him to resolve them. What worries me is not that they apparently dismissed his concerns, they didn't. I immediately noticed the solution to some of his items myself. What does worry me is that they took the debate to a private forum, and even failed to make the solutions public. This is not acceptable for an Open standard.
4. Why should I use the KISS kernel and not realtime Linux?Actually, I am a big proponent of Linux. I have it installed on my laptop, and used it for a short while for cross compiling the KISS kernel to the 68K architecture, before obtaining win32 binaries. In my opinion, Linux will do very well for large embedded systems, where failure is not life-threatening. Linux is preferable in embedded systems where a large display with a familiar graphical user interface is necessary, or where standard desktop applications are desirable, such as web browsers, PDF viewers, etc. However, the Linux kernel is very large. In life-critical applications, it is impossible for a programmer like me to read and understand the entire kernel, so that I may verify the integrity of the whole system. The KISS kernel on the other hand is very small, readable and understandable. I know how it works, and if I encounter a wierd bug in my system, I have a very good idea what to look for. No engineer in his right mind will put Linux in medical equipment, avionics and nuclear power plants, where Linux offers no advantage over standard small realtime kernels. The KISS kernel is also much smaller. After the Linux kernel is stripped to the bare essentials, it is still at least 10 times larger than a similar realtime kernel configuration. In other words, on watches, in microwave ovens and even in the majority of PDAs, Linux offers no advantages, only disadvantage |