1 / 18

Minix Overview & System Call Implementation

Minix Overview & System Call Implementation. Sankara Narayanan. CSE 785 Computer Security, Syracuse University, NY Spring 2003 – 2004. What will be Covered!!!!. Overview of the Minix Operating System The Architecture of Minix Implementation of System Calls – How it works Conclusion.

cael
Télécharger la présentation

Minix Overview & System Call Implementation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Minix Overview & System Call Implementation Sankara Narayanan. CSE 785 Computer Security, Syracuse University, NY Spring 2003 – 2004

  2. What will be Covered!!!! • Overview of the Minix Operating System • The Architecture of Minix • Implementation of System Calls – How it works • Conclusion

  3. Introduction – About Minix • Minix – Mini Unix (Minix) basically, a UNIX -compatible operating system. • Minix is small in size, with microkernel-based design. • Minix has been kept (relatively) small and simple. • Minix is small, it is nevertheless a preemptive, multitasking operating system.

  4. Continued • Modularity in Minix • Multiprogramming (Multiple programs can be run at once) • Source Code – C language • Networking support – TCP/IP protocol

  5. Architecture – Which You must be familiar.. • The figure represents the internal architecture of Minix. Different Layers User Processes init, login, passwd, sh, ls, cp, cc,……….. Server Processes File System (FS), Memory Manager (MM) Kernel I/O Tasks Floppy, tty, clock, system, ………… Kernel Process Management Interrupt handlers 4 3 2 1

  6. Source Code/ Directory Structure • commands • fs – file system • kernel – kernel codes • Solaris • tools • mm – memory manager All these folders you find under your /src folder

  7. System Calls – Flow of Control • The flow of control in minix from the user level the kernel level is handled by system calls. • Minix has a set of system calls which are located in the table.c file. • The file system (fs) has its own table and so the memory(mm), but the number of system calls is fixed.

  8. Continued…System Calls… • System call in minix is similar to a system, call in any system. • A user-level process cannot directly access a disk. Instead it asks the kernel to obtain data from a file for it (the read system call). • A user-level process cannot create another process. Instead, it asks the kernel to create one for it. • User Program ==> Library ----> Kernel ==> MM/FS

  9. Continued…System calls… • System calls are typically made via library routines. Library routines are normal procedure calls. They perform the setup for the system call. • In minix the system call functions in a similar fashion. • The prototype of the libraries are defined in /usr/include/unistd.h or other header files according to the system call

  10. Continued….System Call…. • To implement a system call in minix one needs to do the following steps. • Look for a free slot in the table.c file • Follow the standard convention no_sys, /* 0 = unused */ do_exit, /* 1 = exit */ do_fork, /* 2 = fork */ do_acl /* 77 = acl */  your system call entry

  11. Continued ….. System Call… • The system call would be named in the following manner do_acl or do_encrypt • Once the system call method has been written its declaration should be mentioned in the function declaration header file in the file system it is “proto.h” • _PROTOTYPE ( return type do_XXXX, (arguments if any) );

  12. Continued….System Call… • The library should also be informed about the system call that would be called by the user. • The library file for the system call is written in the lib/posix directory. The file naming convention is followed here it starts with an underscore Eg: - _fork.c (this code is defined in /lib/posix) #include <lib.h> #define fork _fork #include <unistd.h> PUBLIC pid_t fork() { message m; return(_syscall(MM, FORK, &m)); } When you add a new system call, you need to add code as above.

  13. Continued….System Call… • It calls _syscall (MM, FORK, &m);. The first parameter is the destination. This is always MM/FS. When kernel receives a system call request, what the kernel do is to send message to MM/FS. Actual work is done by MM/FS. The second parameter specifies the type of service. The ID is defined in /usr/include/minix/callnr.h . User program cannot call _syscall() or directly. The structure of message is defined in /usr/include/minix/type.h.

  14. Continued….System Call… • Once the code for the system call is written in the "lib/other" directory a system file needs to be created. The system file is present in the "lib/sunsyscall" directory. • A standard naming convention is followed here to. The filename extension is ".s". .global systemcallname systemcallname: ba _systemcallname nop

  15. Continued…System Call… • A system call will contain a user created command file which when compiled creates a binary executable command. the command is created in the “commands/simple”directory”. The file once compiled creates an executable binary in the “commands/simple/bin”directory. • You will need to do a sunread to get the bin from the solaris system to the minix system

  16. Continued…System Call… • All the headers used in the system calls are kept in the "include" directory. The "type.h " header file is a very important and most useful header file. • To pass a message a variable of a specific data type is defined, and the variable is added to the message structure as I had shown in the example below. • The message structure defined is as follows:

  17. Continued…System Call… • Typedef struct { datatype mnYY; } mess_n; n => message number of the message YY => variable name • The size of the structure defined in the message is also an important factor as if the size of the message is increased then the system crashes. • Typedef struct { char *m1sb; } mess_1; #define m1_sb m_u.m_m1.m1sb; • To add data in the message variable the following need to be done Message m; m.m1_sb = data

  18. Conclusion The End Thank You 

More Related