[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proposal for Ttime, etc. in MiNT

>   - The additional POSIX.1b signals can now carry a little bit data (a
>     pointer or an integer value) that can be used to transfer to the
>     signal handler information about why the signal has been caused.
> 
>   - The new signals are queued, which means that if several signals of
>     the same type arrive before the signal handler is called, all of
>     them will be delivered.
> 
>   - POSIX.1b signals have a well-defined delivery order, i.e. you can
>     work now with signal priorities.
> 
>   - A new function sigwaitinfo() allows to wait on signals and to
>     continue quickly after the signal arrived with program execution
>     without the overhead of calling a signal handler first.
> 
> The new queued signals are a necessary prerequisite for the
> implementation of the POSIX.1b asynchronous I/O interface (see below).
> They might also provide a good interface for delivering hardware
> interrupts to user processes.
> 
> New functions for signals are:
> 
>   sigwaitinfo(), sigtimedwait(), sigqueue().
> 
> Implementation status: not yet implemented. Kevin Tran
> <ttran@cs.UCR.edu> has sent me a short note that he has started to do
> some work on POSIX.1b signals for Linux.
> 

Well looks a lot like Fenix messages to me ;-)

> 
> Inter Process Communication (IPC) and memory mapped files
> ---------------------------------------------------------
> 
> POSIX.1b now defines shared memory, messages, and semaphores. The
> functionality and design of these is similar or better than the System
> V IPC mechanisms which we have already in Linux. The major extensions
> compared to System V IPC are:
> 
>   - Strings (like filename paths) instead of integers are used now to
>     identify IPC resources. This will allow to avoid IPC resource
>     collisions much easier than in SysV IPC. The POSIX IPC name space
>     should probably be made visible as a /proc/ipc subdirectory, such
>     that the usual tools like ls and rm can be used to locate and
>     remove stale persistent IPC resources.
> 

Fenix has both of these schemes...

>   - Semaphores come in two flavors: kernel based semaphores (as in
>     System V, which requires a system call for each P/V operation) and
>     now also user memory based semaphores. Kernel based semaphores are
>     sometimes necessary for security reasons, however they are a real
>     pain if you want to build e.g. a high performance database:
>     Suppose there are 20 server processes operating on a single huge
>     B-tree in a memory mapped database file. Inserting a node with
>     minimal blocking of concurrent accesses by the other 19 processes
>     in a large B-tree can require around 100 semaphore operations, and
>     this means currently 100 kernel calls :-(. With POSIX.1b's user
>     memory based semaphores, you put all your semaphores in a piece of
>     shared memory and the library accesses them with highly efficient
>     test-and-set machine code. System calls will then only be
>     necessary in the rare case of a blocking P operation. A high
>     performance database programmer's dream and easy to implement!
> 
>   - In POSIX.1b, both memory mapped files and shared memory are done
>     with the mmap() system call.
> 
> Scheduling
> ----------
> 
: loadsa scheduling stuff deleted

Fenix currently is fully real-time oriented and allows threads to be 
nonpreempted. Memory can also be allocated from a non pagable heap.
And also: Fenix can preempt threads running in supervisor mode!
 

Some people have mailed me asking various questions and since I think that Fenix
development is of somewhat general interest on this list I have taken the
liberty to answer some.

Q: Where is Fenix?
A: Fenix is located on my TT's harddisc. There is a beta coming up real soon!

Q: Why is development so slow?
A: While I'm developing Fenix. I'm also working full time constructing ASICs and
   I'm also writing a development system for video games consoles in my spare
   time. Right now there is time left for about 1h development a day for Fenix. 

Q: But then again why is development so slow?
A: While I have designed the kernel various new things have occured on the
   computer market like JavaOS and Inferno. I have redesigned some parts of
   the kernel to more efficiently support Java and I have also designed a GC.
   The kernel has also been rewritten twice.

Q: What will Fenix look like?
A: I don't know :-) Fenix is actually what you like it to be! It could be a 
   kernel for your 683xx-microcontroller powered toaster or a full fledged GEM
   system. Fenix is fully extensible by simply adding servers. The Fenix 
   nanokernel is pretty stupid (only handles threads,messages and part of the
   memory) the rest of the work is done by servers.

Q: What servers are there?
A: At this moment (960905) there are actually no real servers. There are some
   supportservers which creates and kills threads and message ports and
   initiates heaps. I will personally write the hardware servers corresponding
   it Xbios and Bios calls.

Q: How can I program Fenix-aware programs?
A: Fenix will have a mint/tos/gem emulator which gets messages from the kernel
   when a thread is trapping and translates these traps into messages to           servers. To increase speed this emulator will be located in the kernel and
   the server interfaces will be a lot like the trap interface. But to fully       use Fenix it is more convenient to call the servers directly. Details about
   server interfaces will be released when the beta is released.

Q: Can I get the source code for the kernel?
A: No! But do not worry. The kernel is free and the interesting parts of
   Fenix are the servers which sources mostly will be freely released. The
   reason why the kernel's sources isn't free is that I want to be free to
   change the datatypes in the kernel without worrying about nasty servers.
   There are some servers which use the datatypes of the kernel and the
   sources of those parts won't be freely released either.

Q: Can I help?
A: Yes! There are a lot of servers to be written. If you are serious about
   writing servers you can contact me! The develpment of servers involve
   programming in assembler and C++ or C and you should be familiar with these
   languages.
   Some servers that is not written:
     * Resource server
     * Device Driver server
     * VDI server
     * GEM server (to modify oAESis os Xaaes shouldn't be that hard though..)
     * File server
     * Various Filesystem servers
     * Network server

Q: Wouldn't preempting supervisormode threads complicate interupthandlers?
A: Not at all! The supervisor threads running at ipl of 3 or higher are not
   preempted but the rest is. This means that the "$68" hardware hbl can't be
   used but that is actually no real problem since it's of no real use if you
   are not syncscrolling!

Regards
	Sven Karlsson
---------------------------------------------------------------------------
Student of Engineering Physics at Lund Institute of Technology, Sweden

Soft- and Hardware developer @ Istari Software
Current projects: Code ,an interactive development tool for video
	game consoles including Editor,Debugger and Assembler
        Fenix: A new OO os compatible with tos/gem
E-mail: f92sk@efd.lth.se or tomten@df.lth.se
WWW: http://www.efd.lth.se/~f92sk