(PLAN 1) Interrupt Service Routine or Interrupt Handler (Source: comp.realtime newsgroup)

As I read many articles related to Interrupt handling, I came across so many different definitions on Interrupt Latency, Interrupt Service Routine, and Interrupt handler. So I posted the following messages to the realtime newsgroup.

Date: Mon, 22 Mar 2004 20:07:30 +1200
From: Sang Hyeb Lee 
Newsgroups: comp.realtime
Subject: Interrupt Latency.

Hello.

I'm quite confused about what exactly Interrupt Latency means.
Is it the amount of time that elapses between the physical interrupt
signal being asserted and the interrupt service routine running OR the
amount of time that elaspes between the physical interrupt and the
device driver's interrupt handler?
                                                                       
thanks,
sam

After a while, I got the following answer from the newsgroup.

Date: Mon, 22 Mar 2004 11:11:27 +0100
From: Juergen_Sievers 
Reply-To: never.answer.me@go.away.de
Newsgroups: comp.realtime
Subject: Re: Interrupt Latency.

Hi sam                                                                         

A) Interrupt latency time:
   The time from physically event to the first instruction of the ISP.
                                                                              
B) Scheduling latency time:
   The time from the last instruction of the ISP to the first instruction of
the interrupted process.

C) Context Switch time:
   The time from the last instuctuin of the leaving user process to the
first instruction of the following user process.
                                                                               
Hope it's helpfully and Regards
j.

Aha! So the definition of interrupt latency in [WILLIAMS 2002] was right. The interrupt latency is the amount of time from physical interrupt to the starts of the Interrupt Service Procedure/Routine. However, the definition of scheduling latency time here differs from the one from [WILLIAMS 2002]. In [WILLIAMs 2002], the scheduling latency time is defined as the amount of time that elapses between the interrupt service routine complting and the scheduling function being run.And the scheduling duration is the amount of time that elapses inside the scheduler proper to decide what thread to run and context switch to it. So the definition given in this reply actually refers to both scheduler latency and scheduler duration.

I posted another messages, shown below.

Date: Tue, 23 Mar 2004 11:21:13 +1200
From: Sang Hyeb Lee 
Newsgroups: comp.realtime
Subject: Re: Interrupt Latency.

Hi, Juergen.
                                                                              
Thank you very much for your help. ;) ;)
                                                                               
I've got a couple more questions on basic terminologies.
                                                                              
(1) What does ISP stands for? Does it stand for Interrupt Service Routine?
Shouldn't it be ISR?
                                                                               
(2) What is different between an interrupt service routine and a device
driver's interrupt handler? Does ISP refers to both interrupt service
routine and a device driver's interrupt handler?
                                                                              
Thanks! ;)
                                                                               
Regards,
Sam

Here is the reply

Date: Tue, 23 Mar 2004 13:19:57 +0100
From: Juergen_Sievers 
Reply-To: never.answer.me@go.away.de
Newsgroups: comp.realtime
Subject: Re: Interrupt Latency.

On most new CPUs the Intterupt Service Routine (ISP) runs in a complet
different context. So Interrup Service Process/Procedure (ISP) may
subscribele the situation a littel bit better :)
                                                                               
Interupt Service Rotines reflecting only on an external events. (Excepting:
some/most CPUs have the capabillity to emit software Interrupt to generat
such "!!extern!!" event by software). Such events (Extern and Software
emitted) has well defined priorities!!!.
                                                                       
Some drivers have its own thread or process, controlled by intterupt events
and/or User requests. Those Drivers processes are not interrupt service
processes. Onliy the ISP who takes the external event and signaled the
Drivers Processes are an ISPs.
                                                                       
For example a simple clock driver.
The events from the external clock hardware occures every second and would
be processed from an ISP. Simple he counts up the events and signales the
following processes.
The driver\'s Process is mostly waiting for a semaphore. Remember this
semaphore will be unblocked be the ISP each secound. Then the driver\'s
workerthread may calculete the right time in reflection on the current time
zone eg.

                                      
Die einfachen Kostenz%Gï¿¿%@hlerdurchl%Gï¿¿%@ufe als ISP.
Es dauert allways diegleiche
sehr kurze Zeit und entblockt jedes secound das Semaphor.

                                      
The driver\'s process takes the ISP\'s signal to read the counter and
calculates the right time in reflection on what Day, Month, Jahr,Schaltjahr
eg.

                                      
Why?
a: The ISP takes always the same short time on each event and it's system
load could be calculate.

b: The driver's process has at least one secound to calculate the right
system time. Most it has only to increment the secount part, some times he
has to find out if the 3/29/200X exist or not.

                                      
Sorry about my bad english, but my native language is C and C++ :)
                                                                               
j.

Aha! So on modern CPU, Interrupt service routine runs in a completely different context, so it can be called Interrupt Service Process instead of Procedure/Routine! And I got another useful reply

Date: Tue, 23 Mar 2004 06:44:54 -0700
From: Ed Skinner 
Newsgroups: comp.realtime
Subject: Re: Interrupt Latency.

Again, Juergen's descriptions are very good.
Here is a little more information that may be helpful.
                                                                       
In some architectures, the processor and the I/O device have a brief
conversation when an interrupt is just beginning. The device tells the CPU
it's "vector number" (which was programmed into the device earlier,
probably by the device's software driver). The processor then uses that
number to calculate an execution address (typically using another
processor register called the Vector Base Register) to go "directly" to
the Interrupt Service Routine (ISR).
                                                                        
In other architectures, the initial determination of which device is
causing the interrupt and, therefore, which ISR to use must be handled in
the software (because the hardware is simpler). In these systems, when an
interrupt is just beginning, the processor jumps to a specific memory
location and begins executing whatever code happens to be there. The
operating system puts its own interrupt handler in that specific memory
location so it (the OS) will get control when an interrupt occurs. That
software must figure out which device is causing the interrupt. This is
usually done by interrogating a device called a Programmable Interrupt
Controller, or PIC. The OS's ISR asks the PIC, "Who did it?" and the PIC
gives back some identification. The OS's ISR then uses that value to
figure out which device-specific-ISR to execute (usually by means of some
lookup table). The OS "calls" the device-specific-ISR to continue the
processing.
                                                                      
In this second approach, "ISR" is confusing because some of the processing
is done in the OS (the initial part where the interrupt source is
determined) and some is in what I think of as the device-specific software
(or "device driver").
                                                                        
For that reason, some extra terms may be helpful. The AIX operating system
(a Unix variant from IBM) refers to First-Level Interrupt Handling (FLIH)
and Second Level Interrupt Handling (SLIH) for these two levels. Note that
there is one FLIH (in the Operating System itself) and probably many SLIHs
(one for each device).
                                                                          

In both kinds of architectures, the Operating system may offer some after-
the-interrupt processing service to the device driver. The intention is to
allow the device driver's ISR (SLIH) to "defer" some of the processing it
might need to do to a later time (but not much later). The goal is to
get-in and then get-out of the ISR as quickly as possible to reduce
interrupt latency (for other devices). In operating systems that offer
this capability, the deferred software typically executes after all
interrupts have been processed, and before the OS continues the execution
of any normal program.
                                                                          
This deferred capability goes by any of several names. AIX calls it an
Off-Level Interrupt Handler (OLIH). Linux calls it a Bottom Half, a
Tasklet or a Soft IRQ which are (subtle but important) variations on the
same idea. Some OSs refer to these as Callbacks but that terms has other
meanings also in common use so you'll need to be cautious when someone
talks about them to figure out exactly what they are referring to. And,
finally, some variants of Windows have a similar capability -- I think
they call it a Deferred Procedure Call but I could be mistaken.
                                                              
Hope this helps!

The second approach is used in MINIX,too!!

(PLAN 2) Process model in MINIX (Chapter 2 of OSDI)

(PLAN 3) Bits, flags, braches, tables (Source: Chapter 10 of Assembly Language SBS)

(PLAN 1) Preemptible patch Linux kernel (Source: MORGAN, KEVIN: Preemptible Linux: a Reality Check, MontaVista Software)

There are many characteristics of Linux which makes it unsuitible for Real-time OS. Among them, the two biggest causes for Linux kernel's high response time are the high interrupt latency and high scheduling latency. The interrupt latency is the amount of time that elapses between the physical interrupt signal being asserted and the interrupt service routine running (definition from WILLIAMS, CLARK: Which is better -- the preempt patch, or the low-latency patch? Both!). High interrupt latency resulted from disabling interrupts frequently. The scheduling latency is the amount of time that elapses between the interrupt handler completing and the scheduling function being run. There are some parts of real-time software, such as real-time control software written in Java, which can not be implemented in driver-level software. These program has to be written in user-space. Therefore, the kernel needs to be able to preempt process and switch to a higher priority (newly awoken) very quickly. Originally, Linux kernel itself was non-preemptible. There is now a kernel-preemption patch which speeds up response time by making kernel pre-emptible. To make kernel pre-emptible, they have done the following four things.

(PLAN 2) Comparison between two approaches reducing scheduler latency (Source: WILLIAMS, CLARK: Which is better -- the preempt patch, or the low-latency patch? Both!, March 2002)

There are two approaches to making Linux kernel more responsive by reducing the scheduler latency. These are the preemption patch (by MontaVista Software) and the low-latency patch (by Ingo Molnar). In this article, these two methods are briefly explained and they tested the performance of each method on x86 machine. The results shows that low-latency patch performs slightly better than preemption patch. However, the hybrid method of these two technique performs best. This article gives an example of hardware interrupt handling. It can be summarized as bellows.

(PLAN 3) Design of File System in MINIX (Source: Chapter 5 of OSDI)

(PLAN 4) Macros and external modules (Source: Assembly Language SBS)

(PLAN 1) Accessing BIOS (SOURCE: Assembly language)

(PLAN 2) Overview of File system in general (Source: Minix OS book)

All computer needs to retrive and store information. When a process is running, it can store information in its address space. However, the storage capacity is restired to the size of the virtual address space. And also, when the process is terminated, the information is lost. And the last problem is that some processes needs to share some information at the same time. These problems can be solved by using a larget secondary storage such as hard disk. On this storage, informations are stored in units called files. Files are an abstract mechanism which provides a way to stor information on the disk and read it back. There are many ways files can be structued. The most common approach is an unstructured sequences of bytes. This approach is taken by UNI and MS-DOS. This approach provides a maximum flexibility. The other approach is to have a sequence of fiexed-length records, each with some internal structure. In this model, all read and write operations are based on one record. This approach was used in old OSs where each record was a image of 80-colum punched card. In the last approach, a flie consists of a tree of records, not necessarily all the same length, each containing a key field in a fixed position in record. The tree is sotred on the eky field, to allow rapid searching for a particular key. This scheme is widely used on the large mainfrrame computers still used in some commercial data processing. In MS-DOS and UNIX, there are regular files and directories files. Regular files contains user information whereas directory files are system files used for maintaing the structure of the file system. In Unix, there are also character special files and block special files. Character special files are related to input/output and used to model serial I/O devices. Block special files are used to model disks. Regular files are generally ASCII files and binary files. ASCII files are text files which contains human-readable informations. Binary files means that they are not ASCII files. In old days, OS provides two different kind of files access: sequential access and random access. In seqneutial access, all the data in the files are accessed in order. In random access, any part of file can be accssed directly without accessing the data beside it. Mordern operating system only provides random access. There are many attributes associated with each files. These are protection, password, creator, owner and etc. There are many operations which can be done on a files such as create, delete and open. Directory file is a system file which is used to maintain file system structure. The contents of directory file differs from OS os OS. However, on most of OS, it contains the lists of file names and its disk address. There are many ways files can be stored on disks. The simplest and easiest way is to store each file as a contiguous block of data on the disk. This approach is simple to implement and the performance is excellent because the entire file can be read from the disk in a single operation. However, this approach is not feasible unless the maximum file size is known at the time the file is created and the external fragmentation of the disk can results. The second method is to keep each one as a linked list of disk blocks. This method prevent any spaces to be lost to external disk fragmentation (However, internal fragmentation still occurs in the last block because even the small data occupies the entire block) and directory entry only needs to store the address of the first block. The disadvantages of this method is random access is extremely slow because to access a particular part in the file, we always needs to follow the linked list from the beginning of the file. And also, the amount of disk storage in a block in no longer power of two because the pointer always takes up pa few bytes. The third method is associating a memory-resident table which conatins the pointer word from each block. Using this approach, the entire block is available for data and random access is much easier. Although the chain must still be followed to find a given offset within the file, the chain is entirely in memory, so it can be followed without making any disk referneces. However, the entire table must be in memory all the time. This approach is used in MS-DOS. The last method is associating each file with a table called i-node, which lists the attirbutes and disk address of the file's blocks. This approach is used in UNIX. As said earily, the contents of directory files differ from OS to OS. In MS-DOS. directory files contains many attributes in the directory entires like file name, extension, attributes, time, date, first block size and size of file in bytes. In UNIX, each entry contains just a file name and it's i-node number. All the formation in the i-node. We need to be carefully when choosing the block size. If we use a large allocation unit, every file, event 1-byte file, ties up an entire cylinder. On the other hand, using a small allocation unit means that each file consists of many blocks. Reading each block normally requires a seek and a rotation dealy, so reading file consisting of many small blocks will be slow. So when choosing the optimum block size, we need to take into the account the average file size. So how OS keeps trakc of free blocks? There are two general methods: using a linked lists of disk blocks and a bit map. In linked lists method, each disk block contains the address of free disk blocks. So when there is a large number of free disk blocks, the linked lists will be very large. In bit-map method, a disk with n blocks requires a bit map with n bits. Free blocks are represented by 1s in the map, allocated blocks by 0s. If there is enough main memory to hold the bit map, that method is generally preferable. The rest of the chapter explains about file system consistency, security and virus. Since these issues are not relevant to my thesis topic, I just skimmed through it.

(PLAN 1) MINIX newsgroup (comp.os.minix)

      Date: Thu, 18 Mar 2004 09:42:09 +1300
      From: Sang Hyeb Lee 
      Newsgroups: comp.os.minix
      Subject: Are FS and MM non-preemtable in Minix?
                             
      Hi guys.
                                                                               
      Are FS and MM non-preemtable in Minix?
                                                                               
      Thanks,
      Sam
      

I was not clear of the meaning for preemtability. I thought that if something is non-preemtable, the interrupts are disabled so it can not be stopped. However, I was wrong. The preemtability means that if something is preemtable, there is no re-scheduling so it continues execution even after the hardware interrupt occurs.

      
                                                                                
Date: 18 Mar 2004 09:24:34 -0800
From: Luiz Capitulino 
Newsgroups: comp.os.minix
Subject: Re: Are FS and MM non-preemtable in Minix?
                                                                                
Hi Sang,
                                                                                
Sang Hyeb Lee  wrote in message
news:...
                                                                                
> Are FS and MM non-preemtable in Minix?
                                                                                
 It is not preemtable like the users process (which have the a quantum
time to execute), when FS or MM is executing, the kernel will not stop
then to execute another process.
                                                                                
 There are only one exception: when a interrupt ocurrs.
                                                                                
-- Luiz Fernando N. Capitulino

Hello Luiz.
                                                                                
Thanks for your reply.
                                                                                
I've got another question on non-preemtability of kernel in Minix.
                                                                                
so if the hardware interrupt happens when MM is running, the
interrupt-service routine does some house-keeping for the actual
process which handles interrupt, and after that MM runs again. (No
 Context Switching)
                                                                                
So MM is non-preemtable. Is it right?
                                                                                
Thank you very much for your help.

Now I'm quite clear what the pre-emtability means and what is pre-emtable in Minix. I also got the following reply from Kees J Bot.

That may send an interrupt message to a task, and tasks preempt servers
like MM and FS.  Tasks cannot preempt each other, so a tasks only needs
to worry about the code in interrupt handlers modifying something
unexpectedly.  With lock() and unlock() one can keep such handlers away.

Aha! so when an interrupt handler sends an interrupt message to a task, the task may be scheduled to run so task preempt servers. (I remember there are 3 queues used for scheduling: task queue, server queue, user-process queue. And scheduler always pick the process out of the highest non-empty queue). However, tasks cannot preempt each other, so tasks only needs to worry about the code in interrupt handlers which modifies something unexpectedly. It can be solved by disabling interrupts using lock() and unlock()

 
*Summary* 
(1) MM and FS are preemtable in Minix (but not ilke user process which gets 
    interrupted by timer at fixed interval)
(2) When an interrupt occurs, a task for which handles that interrupt might be 
    re-scheduled to run so task preempt servers.
(3) Tasks can not preempt each other. So tasks only needs to worry about the 
    code in interrupt handler which modifies something unexpectedly. This 
    problem can be solved by disabling interrupts using lock and unlock() 
    which call cli() and sti() respectively!

(PLAN 2) software interrupt in DOS (SOURCE: Assembly Language SBS)

The software is a interrupt which does not interrupt anything! ;) This sounds a bit odd. The nature of software can be best explained by an example. DOS contains a little sequences of machine instructions tucked away within itse.f Each sequence does something useful (e.g. display a line of character to the screen, print something). These sequences are used inside DOS and also these sequences are available for the programmer as well. Since DOS is evolving, we can not just remember the absolute address of each sequences, So what they have done is to have a special table (Interrupt Vector Table) at the very start of real mode memory. Each entry (Interrupt Vector) contains an address. None of address is burned into permanenet memory the way BIOS routines are. When the machine starts up, DOS and BIOS fill many slots in the interrupt vector table with addresses of certain service routines with themselves. The x86 CPUs include a machine instruction that makes use of the interrupt vector table. The INT (INTerrupt) instruction causes a software interrupt. For example, when an INT 21H instruction is executed, the CPU goes down to the interrupt vector table, fetches the address from slot 21H, and then jumps execution to the address stored in slot 21H. So how does the interrupt service routine know where to resume the execution of the process? It simply pushes the address of the next instruction on the stack before it jumps to the address in the interrupt vector. Software interrupts can be thought as ways to request services to the kernel. Whereas hardware interrupts can be thought as CPU's mechnism for paying attention to the world outside itself. The only difference between hardware and software interrupts is in the event that triggers the trip through the interrupt vector table. With a software interrupt the triggering event is part of the software; INT instruction. With a hardware interrupt, the triggering event is an electrical signal applied to the CPU chip itself without any INT instruction taking a hand in the process.

(PLAN 1) Memory Management in Minix (Chapter 4 of Minix OS Book)

(*) Memory management in general.

(*) Memory managament in Minix

(PLAN 2) Study basic Intel x86 Instruction sets

(PLAN 3) Modifying and recompiling nel source code

(PLAN 1) playing with MS-DOS and Bochs

I spent most of the afternoon installing bochs (Intel x86 emulator) and installing ms-dos 6.22 on bochs. And also, I examined the configuration file for bochs. I am planning to run & test minix and other operating system on bochs. The bochs configuration file was quite easy to set up. To set up a x86 system running MS-DOS, i first created a 30MB hard disk image using bxshare program. I then wrote a configuration file for a system with 32 memory with a 30MB hard disk, one 1_44 floppy disk, a rom bios, and a elpin video rom. I then started up my new system with a ms-dos installation disk image in a floppy disk drive and installed ms-dos 6.22 onto my system! I will be working on ms-dos 6.22 to learn Intel x86 assembly language.

(PLAN 2) chapter 5 (Memory architecture in Intel x86 system) of Assembly language book

I read about how memories are organized in Intel x86 system. There are 3 major different ways in which memory is organized. These are real mode flat model, real mode segmented model, and protected mode flat model. Some OS concepts, which did not make sense before, are getting clearer as I learn assembly language.

(PLAN 3) Real-time and embedded system guide by Herman bruyninckx

This article provides a general overview on real-time and embedded system. At the moment, I am reading chapter 4.

(PLAN 1) Chapter 3 Of MINIX OS book(Continued)

(PLAN 2) read 2 embedded system papers.

• A Real-time Linux By Bivtor Yodaiken and Michael Barbanov

This paper explains how real-time version of Linux is implemented. In their implementation, Linux is ran as a completely preemptable task on a small real-time micro-kernel. In their design, only small changes need to be made to Linux kernel. These are low level interrupt wrappers and the routines to disable and enable interrupts. Linux has a high interrupt latency (the time from interrupt to task run) so this property makes not suitable for Real-time OS. Linux disables interrupt quite often and also kernel itself is not preemptable.

so intetading of letting Linux handle interrupt hard ware directly, there is a global flag in real-time kernel which is set when Linux wants to enalble interrupts, and similarly reset when interrupts needs to be disabled.

When Linux requests interrupts to be disabled, the real-time microkernel makes the interrupts ad pending. When linux requests interrupts to be enabled, th ereal-time kernel causes control to switch to the Linux handler for highest priority pending interrupt. Linux is then able to provide sophisticated services to the real-time system without increasing interrupt latency.

There are also many disadvantages of this method. These are well explained in "SMX vs Linux" article. This real-time Linux is also well explained in Michael's master thesis "Linux as a Real-time Operating System".

• Implementing Real-Time services in MINIX by Gabriel A. Wainer (1995)

In this article, Wainer explains how he implemented real-time servieces into Minix. This was achived by simply modifying the original MINIX round-robin time scheduling mechanism to th real-time scheduling algorithm. And also some system calls and signals were added as an interface between the kernel and applications.

(PLAN 3) other..

I read an article "SMX vs RT-Linux", which explains why Linux is not suitable as an OS for embedded system. It argues that Linux and even RT-Linux (RealTime-Linux) are not suitable for embedded system OS. The reasons includes non-preemptable tasks resulting in a long interrupt latency, big size, multi-process, IPC, and etc. It should be useful when designing a embedded minix.

(PLAN 1) Chapter 3 of MINIX OS book

I spent most of the day reading chapter 3 of MINIX OS book. This book explains the principle of I/O device drivers and how they are implemented in MINIX. There are two kinds of I/O devices: block devices and character devices. A Block device is one that stores information in fixed-size blocks, each one with its own space. A good example of a block device is disks. A character devices is one which delivers or accepts a stream of characters, without regard to any block structure. It is not addressable. Printers, network interfaces, mouse and most other devices tha t are not dist-like can be clssfied as character devices. I/O unit typically consists of a I/O controller and a device. I/O controller is an electronic component which does all messay stuff related to controlling I/O device. OS always deals with the controller. DMA (Direct Memory Access) were discussed. This controller allows the communication between the buffer in I/O device controller and memory without help of CPU. I/O software can be structured in the following four layers:

1) Interrupt handlers

2) Device Drivers

3) Device independent OS software

4) User-level software

These four layers are explained. And also Deadlock is also discussed in detail. Finally, many device drivers including RAM Disk (which allows some part of memory to be reserved to be used like disk space), hard disk, floppy disk, and clock device drivers were explained in detail.

(PLAN 3) Otherthing

I found a very useful website which explains MINIX boot-sequence in a great details. The website address is http::www.swartzbaugh.net/minix/index.php. This site explains bootsequence very well by going through each line of source code.

I finished reading the chapter 2 of MINIX book. The second half of the chapter 2 was really helpful in understanding how MINIX actually handles boot-up, interprocess communication, process scheduling and all other process related stuff. In page 145 of this book, the author actually gave some useful hints on using MINIX on small system.

"MINIX is also intended to run on small systems, which are likely to have only, one use ror perhaps just a few trusted users. On such a system a user oculd very well want to write an application program that accesses I/O ports, for instance, for use in scientific data acquistion. The file system has a little secret built into it- when the files /dev/mem or /dev/kmem are opened, the memory task calls enable_iops, which changes the privilege level for I/O operations, allowing the current proces to execute insturctions which read and write I/O ports"

I might be able to use it when implementing MINIX on embedded system. It can be useful when providing a faster I/O device handling". I also found "Interrupt handling in MINIX" part useful; however, i should have a better understanding of assembly language before I can fully understand what is actually going on.

I read a book called "Introduction to Assembly Language programming" to know more about Intel 80x86 processer and computer architecture. I also decided to read this book since "booting process" in minix is mostly written in assembly language. I read Chapter 1 and 2. In chapter 1, the author argues that using assembly language on embedded system and real-time application is very useful because assembly language is more time-efficient and space-efficient. The rest of chapter 1 talked about the disadvantages and advantages of using assembly language. In chatper 2, the basic computer organization is well explained. I learnt a lot about computer architecture. I will write some of stuffs I learnt today here.The basic computer system consists of a CPU, I/O devices, and memory. The system bus is used to connect them. The system bus consists of address bus, data bus, and control bus. The address bus is used to address a specific memory locatoin. The width of address determines the maximum amount of addressable physical memory. For example, 80x86 has a 20-bit address bus. The data bus is used to transfer data. The width of data bus determines the maximum number of data which can be transferred at a time. For example, 80x86 has a 16-bit data bus. And control bus is used to signal a various control actions such as memory read, memory write, I/O stuffs. And it talks about pentium memory architecture and different types of memory. I really found the chapter 2 of this book useful.

I also started reading a book called "Operating system concepts" to understand MINIX better. It should help me have more clear understanding of operating systems. At the moment I'm reading a chapter 2. It really gives me a better understanding of OS concepts. I should keep reading this book.

PAPER SUMMARY) Embedded Software by Edward A. Lee (2002)

This paper says that embedded system differs from conventional software because embedded system needs to take care of timeliness, concurrency, liveness, reactivity, and so on. It argues that embedded software needs to be taken differently from conventional software so that a new model of design strategy should be taken. This paper kinds of states the requirements of embedded system. and also it lists a lot of computation models which can be applied to embedded software. It is kinda hard to understand at the moment. I should read another paper and get back to this one later.

I've searched the citeseer and found a bunch of useful papers on "Embedded system".

I have read a chapter 2 "process management" of MINIX OS book and found the following useful.

Bootstrapping MINIX

(1) When the computer hardware is turned on, the first sector of the first track of the boot disk is loadded into memory.

(2) The first sector contains a partition table and a small program. That program reads the partition table and loads and executes the first sector of the active parition.

(3) The bootstrap on the active partition loads boot program for the partition.

(4) Boot looks in the second sector of its partition to find a set of parameters to use and loads operating system image according to the configuration. (ASIDE: Like standard UNIX, MINIX reserves It loads OS image by looking for a file called /minix. The different image can be loadded by passing an appropriate parameter.

I spent most of day building this project webpage. And also, I finished planning for my project. I found an useful quote from 'how to be a good thesis student guide':

"Keeping a research journal or diary of your research activities and ideas is very useful. Write down speculations, interesting problems, possible solutions, random ideas, references to look up, notes on papers you've read, outlines of papers to write, and interesting quotes. Read back through it periodically."

I also spent some time looking at some minix source code. I'd better spend more time on literature review. I have not found any useful papers yet.

I read also an article 'Introduction to Real time". It explains basic terminology used in real time system. It is a quite useful article. The URL is http://www.embedded.com/showArticle.jthml?articleID=9900353

I had a meeting with my supervisor. We talked mostly about our proposal and plans for my thesis. Here is a brief ideas of what I need to do for my thesis.

(1) Requirement of embedded systems

eg) small, fast, real-time

(2) Difference between Real OS and Normal OS

(3) Simulate what they'v edone in Linux in Minix

(4) Current status on Real time embedded OS

TO DO>> (1) Search gogle about embedded system, minix, linux

(2) ACM digital Journal

(3) plan

My supervisor suggested me to look very carefully on how minix is loaded into the memory.