The kernel is just a function like any other, but which runs forever.
kernel( ) { initialize( ); FOREVER { request = getNextRequest( ); handle( request ); } }
There are two other ways of writing the kernel, which are both equivalent to the one above.
kernel-start: initialize( ); exit-kernel( ); kernel-entry: request = determine-request( ); handle( request ); exit-kernel( );
And
kernel-start: initialize( ); exit-kernel( ); create-entry: handle( CREATE ); exit-kernel( ); xxxx-entry: and so on;
The first one is the most common. It hides all the interesting stuff inside
int getNextRequest( ) { active = schedule( ); //active is a pointer to a TD activate( active ); return determine-request( active ); //the active task doesn't change }
What's inside activate( active )
?
iretl
int n
How do you get the right PC into the interrupt vectors?
Each task is a C function
hello-world.c
So is the kernel
kernel.c
Each gets compiled and linked into an ELF executable
Then 452-post.py
(/u/cs452/public/tools/bin/452-post.py
) binds the ELFs together
to be downloaded.
Before starting to execute the kernel needs to have
The boot loader does this. How?
int main( unsigned long magic,
multiboot_info_t *mbiaddr )
mbiaddr, magic
multiboot_info_t
is a struct with the following
interesting fields
typedef struct multiboot_info { ... unsigned long mods_count; unsigned long mods_addr; ... } multiboot_info_tThe second is a pointer to
module_t
, the first module
record.typedef struct module { unsigned long mod_start; unsigned long mod_end; unsigned long string; ... } module_t
You might find these URLs have some interesting information (and links) if you are really interested in how executables are structured.
http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html
or in the multiboot boot process
http://www.gnu.org/software/grub/manual/multiboot/multiboot.html
Return to: