1 / 69

Lecture 2: UNIX STRUCTURE

Lecture 2: UNIX STRUCTURE. UNIX. User Interface. The layers of a UNIX system. Essential Unix Architecture. Applications. System Libraries (libc). System Call Interface. I/O Related. Process Related. File Systems. Scheduler. Modules. Networking. Memory Management. Device Drivers.

jude
Télécharger la présentation

Lecture 2: UNIX STRUCTURE

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. Lecture 2: UNIX STRUCTURE

  2. UNIX UserInterface The layers of a UNIX system.

  3. Essential Unix Architecture Applications System Libraries (libc) System Call Interface I/O Related Process Related File Systems Scheduler Modules Networking Memory Management Device Drivers IPC Architecture-Dependent Code Hardware

  4. UNIX Utility Programs A few of the more common UNIX utility programs required by POSIX

  5. FreeBSD machine independent kernel code

  6. FreeBSD machine dependent kernel code

  7. Kernel services • Border between kernel level and user level code is supported by the hardware protection • Kernel is working in completely isolated address range and it’s impossible to get access to that address space from user level • Any interaction between user level code and kernel possible only by means of system call, which are strictly controlled by the kernel • In most cases system calls are synchronous for user level application. • But it is possible that kernel will make some work sometimes after it returns results to the user level. • In most cases system call is implemented by the means of hardware exception, that change CPU working mode and current virtual memory content • Kernel is controlling system call arguments very strictly before executing the system call. • Every system call arguments will be copied to the kernel address space in order to garantee, that arguments will not be changed during the system call • The addreses, where the result of the system call will be placed, have to be owned by the process, who called system call (checked) • If system call got an error, it returns -1 and sets global errno variable.

  8. System Calls for process control fork() wait() execl(), execlp(), execv(), execvp() exit() signal(sig, handler) kill(sig, pid) System calls for low level file I/O creat(name, permissions) open(name, mode) close(fd) unlink(fd) read(fd, buffer, n_to_read) write(fd, buffer, n_to_write) lseek(fd, offest, whence) System Calls for IPC pipe(fildes) dup(fd) Total ~270 System Calls in Linux kernel v2.6 Portable Operating System Interface (POSIX) ISO/IEC 9945 IEEE 1003 Single UNIX Specification (SUS) Linux Standard Base System Calls

  9. System Calls for Process Management s is an error code pid is a process ID residual is the remaining time from the previous alarm

  10. System Lifecycle: Ups & Downs start_kernel sleep? (hlt) LILO shutdown init Poweron Poweroff Boot-loader KernelInit OS Init RUN! Shutdown

  11. Processes Process 0: Kernel bootstrap. Start process 1. kernel kernal mode user mode Process 1: create processes to allow login. /etc/init fork exec fork exec inetd lpd condition terminal for login /etc/getty /etc/getty httpd exec exec check password /bin/login /bin/login exec exec command interpreter shell shell

  12. Processes • Processes can run in 2 different modes: user level and kernel level • Process can switch between these two modes by means of system calls • Process resources also can be divided into two parts: user level process resources and kernel level process resorces • User level process resources – CPU general pursope registers, command counter, CPU state registers, stack registers, process memory segments (text segments, data sements, shared lib., stack), • Kernel level resources – in most cases resources, which are important for underlying hardware: registers, command counter, stack pointer, schedule information, system call information and etc. • Process kernel state divided into two parts: process structure and user structure • Process structure contains data information, which have to be always in memory and can’t be swapped out. It have to contain pointers to all other resident structures. • User structures have to be residently in memory only during process execution. Otherwise it can be swapped out to the disk. • User structures can be dynamicly allocated to process by the means of memory managenet routines. • Multitasking programming can be achieved by the context switching. And because context switching operations take place very often,minimizing cotext switching time is effective way to achieve better performance.

  13. Parts of process memory structure • user-id • open files • saved register states • environment switches on system call (trap, software interrupt) Stack frames of invoked functions • Initialised data • Non-initialised data • arena/heap • malloc Program code bash$ size testhand2 92763 + 7564 + 2320 = 102647

  14. Every process have uniq identifier – PID. It’s a common mechanism, how kernel and other processes can communicate with each other. • Process structure contains • Process identifier PID • Signal state: waiting signals, signal mask and signal action summary • Profiling information • Timers: realtime timers and CPU usage counters • Different process substructures • Process group identification: process group and session it belongs to • User mandats: actual, effective and stored user and group identification • Memory management describe virtual adress space for every process in the system. • File descriptors: array of pointers to the files, indexed by file decriptors and open file flags. • System call vector. It is possible to run object files, compiled for different UNIX systems, by using different system call vector for different object files. • Resource accounting: rlimit structure, which is used for accounting different system resources. • Statistics: information got from working processes and which are written to accounting file at the time process exit, include process timers and profiling information if it’s necessary. • Signal action: action to be taken when signal send to process • Thread structure.

  15. process structure Stack Stack Stack kernel stack/u area kernel stack/u area kernel stack/u area Data Data Data Text (shared) Text (shared) Text (shared) Big Picture: Another look kernel memory

  16. struct proc { LIST_ENTRY(proc) p_list; /* (d) List of all processes. */ TAILQ_HEAD(, ksegrp) p_ksegrps; /* (c)(kg_ksegrp) All KSEGs. */ TAILQ_HEAD(, thread) p_threads; /* (j)(td_plist) Threads. (shortcut) */ TAILQ_HEAD(, thread) p_suspended; /* (td_runq) Suspended threads. */ struct ucred *p_ucred; /* (c) Process owner's identity. */ struct filedesc *p_fd; /* (b) Open files. */ struct filedesc_to_leader *p_fdtol; /* (b) Tracking node */ /* Accumulated stats for all threads? */ struct pstats *p_stats; /* (b) Accounting/statistics (CPU). */ struct plimit *p_limit; /* (c) Process limits. */ struct sigacts *p_sigacts; /* (x) Signal actions, state (CPU). */ /* * The following don't make too much sense. * See the td_ or ke_ versions of the same flags. */ int p_flag; /* (c) P_* flags. */ int p_sflag; /* (j) PS_* flags. */ enum { PRS_NEW = 0, /* In creation */ PRS_NORMAL, /* threads can be run. */ PRS_ZOMBIE } p_state; /* (j/c) S* process status. */ pid_t p_pid; /* (b) Process identifier. */

  17. LIST_ENTRY(proc) p_hash; /* (d) Hash chain. */ LIST_ENTRY(proc) p_pglist; /* (g + e) List of processes in pgrp. */ struct proc *p_pptr; /* (c + e) Pointer to parent process. */ LIST_ENTRY(proc) p_sibling; /* (e) List of sibling processes. */ LIST_HEAD(, proc) p_children; /* (e) Pointer to list of children. */ struct mtx p_mtx; /* (n) Lock for this struct. */ /* The following fields are all zeroed upon creation in fork. */ #define p_startzero p_oppid pid_t p_oppid; /* (c + e) Save ppid in ptrace. XXX */ struct vmspace *p_vmspace; /* (b) Address space. */ u_int p_swtime; /* (j) Time swapped in or out. */ struct itimerval p_realtimer; /* (c) Alarm timer. */ struct rusage_ext p_rux; /* (cj) Internal resource usage. */ struct rusage_ext p_crux; /* (c) Internal child resource usage. */ int p_profthreads; /* (c) Num threads in addupc_task. */ int p_maxthrwaits; /* (c) Max threads num waiters */ int p_traceflag; /* (o) Kernel trace points. */ struct vnode *p_tracevp; /* (c + o) Trace to vnode. */ struct ucred *p_tracecred; /* (o) Credentials to trace with. */ struct vnode *p_textvp; /* (b) Vnode of executable. */ sigset_t p_siglist; /* (c) Sigs not delivered to a td. */ char p_lock; /* (c) Proclock (prevent swap) count. */ struct sigiolst p_sigiolst; /* (c) List of sigio sources. */ int p_sigparent; /* (c) Signal to parent on exit. */ int p_sig; /* (n) For core dump/debugger XXX. */ u_long p_code; /* (n) For core dump/debugger XXX. */ u_int p_stops; /* (c) Stop event bitmask. */ u_int p_stype; /* (c) Stop event type. */

  18. char p_step; /* (c) Process is stopped. */ u_char p_pfsflags; /* (c) Procfs flags. */ struct nlminfo *p_nlminfo; /* (?) Only used by/for lockd. */ struct kaioinfo *p_aioinfo; /* (c) ASYNC I/O info. */ struct thread *p_singlethread;/* (c + j) If single threading this is it */ int p_suspcount; /* (c) Num threads in suspended mode. */ struct thread *p_xthread; /* (c) Trap thread */ int p_boundary_count;/* (c) Num threads at user boundary */ struct ksegrp *p_procscopegrp; /* End area that is zeroed on creation. */ #define p_endzero p_magic /* The following fields are all copied upon creation in fork. */ #define p_startcopy p_endzero u_int p_magic; /* (b) Magic number. */ char p_comm[MAXCOMLEN + 1]; /* (b) Process name. */ struct pgrp *p_pgrp; /* (c + e) Pointer to process group. */ struct sysentvec *p_sysent; /* (b) Syscall dispatch info. */ struct pargs *p_args; /* (c) Process arguments. */ rlim_t p_cpulimit; /* (j) Current CPU limit in seconds. */ signed char p_nice; /* (c + j) Process "nice" value. */ /* End area that is copied on creation. */ #define p_endcopy p_xstat u_short p_xstat; /* (c) Exit status; also stop sig. */ struct knlist p_klist; /* (c) Knotes attached to this proc. */ int p_numthreads; /* (j) Number of threads. */ int p_numksegrps; /* (c) Number of ksegrps. */ struct mdproc p_md; /* Any machine-dependent fields. */ struct callout p_itcallout; /* (h + c) Interval timer callout. */

  19. u_short p_acflag; /* (c) Accounting flags. */ struct rusage *p_ru; /* (a) Exit information. XXX */ struct proc *p_peers; /* (r) */ struct proc *p_leader; /* (b) */ void *p_emuldata; /* (c) Emulator state data. */ struct label *p_label; /* (*) Proc (not subject) MAC label. */ struct p_sched *p_sched; /* (*) Scheduler-specific data. */ };

  20. Processes in UNIX Process creation in UNIX.

  21. Threads

  22. Threads in POSIX The principal POSIX thread calls.

  23. UNIX Scheduler The UNIX scheduler is based on a multilevel queue structure

  24. Process status: NEW, NORMAL (RUNNNABLE, SLEEPING, STOPPED), ZOMBIE • Kernel uses 2 queues to hold processes in different states: zombieproc and allproc. • In most cases threads are organiezed in 2 queues – runnable queue and waiting queue. • Threads, which are ready for running going to runnable queue and threads, which are waiting for some something placed in waiting queue. • Queues are organized based on process and threads priority values. Waiting queue hashed based on event ID in order to make search operation faster. • Processes are organized in groups

  25. Process can be created by using pid_t fork(void); pid_t rfork(int flags); pid_t vfork(void); sysytem call • Child process created by fork() is an exact copy of parent process except for the following: • The child process has a unique process ID. • The child process has a different parent process ID (i.e., theprocess ID of the parent process). • The child process has its own copy of the parent's descriptors. These descriptors reference the same underlying objects, sothat, for instance, file pointers in file objects are sharedbetween the child and the parent, so that an lseek(2) on adescriptor in the child process can affect a subsequent read(2)or write(2) by the parent. This descriptor copying is alsoused by the shell to establish standard input and output fornewly created processes as well as to set up pipes. • The child process' resource utilizations are set to 0; seesetrlimit(2). • All interval timers are cleared; see setitimer(2). • Child process created by rfork() is an exact copy of parent process except for the following: Forking, vforking or rforking are the only ways new processes are created. The flags argument to rfork() selects which resources of theinvoking process (parent) are shared by the new process (child) or initialized to their default values. The resources include the open filedescriptor table (which, when shared, permits processes to open and closefiles for other processes), and open files. • The vfork() system call can be used to create new processes without fullycopying the address space of the old process, which is horrendously inefficient in a paged environment. It is useful when the purpose of fork(2)would have been to create a new system context for an execve(2). Thevfork() system call differs from fork(2) in that the child borrows theparent's memory and thread of control until a call to execve(2) or anexit (either by a call to _exit(2) or abnormally). The parent process issuspended while the child is using its resources.

  26. Process exit ether by using exit() call or by reciving signal. In either way, process exit status is delivered to parent process by wait4() system call.

  27. POSIX Signals The signals required by POSIX.

  28. System Calls for Memory Management • s is an error code • b and addr are memory addresses • len is a length • prot controls protection • flags are miscellaneous bits • fd is a file descriptor • offset is a file offset

  29. System Calls for File Management • s is an error code • fd is a file descriptor • position is a file offset

  30. UNIX File System (1) Disk layout in classical UNIX systems

  31. The lstat System Call Fields returned by the lstat system call.

  32. System Calls for Directory Management • s is an error code • dir identifies a directory stream • dirent is a directory entry

  33. System Calls for File Protection • s is an error code • uid and gid are the UID and GID, respectively

  34. bin etc users tmp usr Disk vs. Filesystem • The entire hierarchy can actually include many disk drives. • some directories can be on other computers / hollid2 scully

  35. Architecture: File System Structure • Hierarchical / bin dev etc home lib mnt proc tmp usr var passwd group bin man sbin

  36. Directory Structure • /bin • The bin directory is where all the executables binaries were kept in early Unix.Over time, as more and more executables were added to Unix, it became quite unmanageable to keep all the executables in one place and the bin directory split into multiple parts(/bin/sbin, /usr/bin) • /dev • Device drivers (screen, keyboard, harddisks etc.) • /etc • Unix designates the etc directory as the storage place for all the adminstrative files and information. • /lib • If programs want to include certain features,they can reference just the shared copy of that utility in the Unix library rather than having a new unique copy. • /lost+found • When files are recovered after any sort of problem or failure,they are placed in the lost + found directory, if the kernel cannot ascertain the proper location in the system. • /mnt • The mnt directory is an empty directory reserved for mounting removable filesystems like hard disks,removable cartridge drives, and so on. • /tmp • The tmp directory contains temporary files created by Unix system programs. You can remove any temporary file that does not belong to a running program. • /usr • The usr directory consists of several subdirectories that contain additional Unix commands and data files. • /home • Default location of user home directories. • /var • Logfiles, spools (mailqueue)

  37. Fedora Linux Directories [root@unix /]# ls -l total 237 drwxr-xr-x 2 root root 4096 Sep 20 17:19 bin drwxr-xr-x 4 root root 1024 Sep 20 16:04 boot drwxr-xr-x 23 root root 155648 Sep 20 16:13 dev drwxr-xr-x 41 root root 4096 Sep 20 17:19 etc drwxr-xr-x 2 root root 4096 Mar 12 2004 home drwxr-xr-x 2 root root 4096 Mar 12 2004 initrd drwxr-xr-x 9 root root 4096 Sep 20 17:19 lib drwx------ 2 root root 16384 Sep 20 19:00 lost+found drwxr-xr-x 2 root root 4096 Apr 14 20:39 misc drwxr-xr-x 5 root root 4096 Sep 20 16:13 mnt drwxr-xr-x 2 root root 4096 Mar 12 2004 opt dr-xr-xr-x 50 root root 0 Sep 20 19:12 proc drwxr-x--- 2 root root 4096 Sep 20 17:06 root drwxr-xr-x 2 root root 12288 Sep 20 17:19 sbin drwxr-xr-x 2 root root 4096 Mar 12 2004 selinux drwxr-xr-x 8 root root 0 Sep 20 19:12 sys drwxrwxrwt 2 root root 4096 Sep 20 17:28 tmp drwxr-xr-x 14 root root 4096 Sep 20 16:03 usr drwxr-xr-x 18 root root 4096 Sep 20 16:10 var [root@unix /]#

  38. Security in UNIX Some examples of file protection modes

  39. passwd, shadow, group files unix etc # ls -l passwd shadow group -rw-r--r-- 1 root root 705 Sep 23 15:36 group -rw-r--r-- 1 root root 1895 Sep 24 18:20 passwd -rw------- 1 root root 634 Sep 24 18:22 shadow unix etc # unix root # more /etc/passwd root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/bin/false daemon:x:2:2:daemon:/sbin:/bin/false adm:x:3:4:adm:/var/adm:/bin/false lp:x:4:7:lp:/var/spool/lpd:/bin/false sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt ... guest:x:405:100:guest:/dev/null:/dev/null nobody:x:65534:65534:nobody:/:/bin/false girtsf:x:1000:100::/home/girtsf:/bin/bash dima:x:1001:100::/home/dima:/bin/bash guntis:x:1002:100::/home/guntis:/bin/bash students:x:1003:100::/home/students:/bin/bash unix root # unix root # more /etc/group root::0:root bin::1:root,bin,daemon daemon::2:root,bin,daemon sys::3:root,bin,adm adm::4:root,adm,daemon tty::5:girtsf disk::6:root,adm lp::7:lp mem::8: kmem::9: wheel::10:root,girtsf floppy::11:root mail::12:mail ... users::100:games,girtsf nofiles:x:200: qmail:x:201: postfix:x:207: postdrop:x:208: smmsp:x:209:smmsp slocate::245: portage::250:portage utmp:x:406: nogroup::65533: nobody::65534: unix root # unix root # more /etc/shadow root:$1$VlYbWsrd$GUs2cptio.rKlGHgAMBzr.:12684:0::::: halt:*:9797:0::::: ... guest:*:9797:0::::: nobody:*:9797:0::::: girtsf:$1$u6UEWKT2$w5K28n2iAB2wNWtyPLycP1:12684:0:99999:7::: dima:$1$BQCdIBdV$xzzlj4s8XT6L9cLAmcoV50:12684:0:99999:7::: guntis:$1$fiJF/0BT$Py9JiQQL6icajjQVyMZ7//:12684:0:99999:7::: students:$1$wueon8yh$nLpUpNOKr8yTYaEnEK6OJ1:12685:0:99999:7::: unix root #

  40. Terminal Management The main POSIX calls for managing the terminal

  41. Different Shells • Bourne • C Shell • Korn Shell • BASH Last login: Tue Sep 21 07:58:17 2004 from 81.198.226.108 [root@unix root]# [root@unix root]# ps PID TTY TIME CMD 20879 pts/7 00:00:00 bash 20905 pts/7 00:00:00 ps [root@unix root]# [root@unix root]# ls -l total 64 -rw-r--r-- 1 root root 1204 Sep 20 16:11 anaconda-ks.cfg -rw-r--r-- 1 root root 49872 Sep 20 16:11 install.log -rw-r--r-- 1 root root 2306 Sep 20 16:11 install.log.syslog [root@unix root]# [root@unix root]# pwd /root [root@unix root]#

  42. Illustration of Process Control Calls

  43. POSIX Shell A highly simplified shell

  44. Environment variables. Ieejot sistēmā, lietotājam automātiski tiek iestādītas dažas “environment variables”. Lai tos aplūkotu, jāizpilda komandu env. Piemēram: • PWD=ceļš #kur atrodamies • TZ=(EET) #laiku zona (East European Time) • PAGER=(less, more) #lasītājs pēc noklusēšanas • LOGNAME=vārds #lietotāja vārds • HOME=/home/vārds #lietotāja mājas katalogs • HOSTNAME=resursdators #resursdatora vārds • LD_LIBRARY_PATH=:ceļš #dinamiskās bibliotēkas • MANPATH=:ceļš #ceļš, kur meklējas “manual” • ENV=/etc/bash_common #kur ir “environment variables” • LESS=-fdeiMQw #atslēgas lasītājam pēc noklusēšanas

  45. Environment variables (Turpinājums). • EDITOR=/usr/local/bin/joe #redaktors pēc noklusēšanas • TERM=vt100 #termināla tipa uzstādīšana (lietotājam) • PS1= \u@\h (\w) #aicinājuma formāts • Machtype=mašīnas_tips #mašīnas tips (aparatūra) • MAIL=ceļš #fails, kur noliek ieejošo pastu • RHOST=hosta_adrese #kādā datorā mēs esam • SHELL=ceļš #lietotāja komandinterpretators • HOSTTYPE=hosta_tips # resursdatora tips • OSTYPE=OS _tips #OS tips (solarisN.N, utl.) • PATH=ceļš:jauns_ceļš #meklēšanas saraksts. Ar to palīdzību tiek meklēti izpildāmi faili • LESSCHARSET=latin1 #attēlu kodētājs • _=ceļš #kur atrodas atbilstošais fails (env)

  46. Environment Variables [root@unix /]# env HOSTNAME=unix.mii.lu.lv TERM=vt100 SHELL=/bin/bash HISTSIZE=1000 SSH_CLIENT=::ffff:81.198.226.108 1289 22 SSH_TTY=/dev/pts/3 USER=root LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01: USERNAME=root MAIL=/var/spool/mail/root PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/root/bin INPUTRC=/etc/inputrc PWD=/ LANG=en_US.UTF-8 SHLVL=1 HOME=/root BASH_ENV=/root/.bashrc LOGNAME=root SSH_CONNECTION=::ffff:81.198.226.108 1289 ::ffff:159.148.108.245 22 LESSOPEN=|/usr/bin/lesspipe.sh %s G_BROKEN_FILENAMES=1 _=/bin/env OLDPWD=/sys [root@unix /]#

  47. The ls Command Steps in executing the command ls type to the shell

  48. The /proc pseudo filesystem • The /proc virtual filesystem is a switch in the configuration of the Linux kernel, one that is turned on by default. If, for whatever reason, you would like to completely disable /proc on your system, de-select /proc file system support within the File system configuration section of config, menuconfig, or xconfig when rebuilding your kernel. Alternatively, you can simply comment out the /proc line in /etc/fstab to prevent it from being mounted.

  49. The /proc pseudo filesystem • The /proc directory contains virtual files that are windows into the current state of the running kernel. This allows the user to peer into a vast array of information, effectively providing them with the kernel's point-of-view within the system. In addition, the user can use the /proc directory to communicate particular configuration changes to the kernel. • /proc directory contains files that are not part of any filesystem associated with your hard disks, CD-ROM, or any other physical storage device connected to your system (except, arguably, your RAM). Rather, these files are part of a virtual filesystem, enabled or disabled in the kernel when it is compiled. • The /proc virtual filesystem is a switch in the configuration of the kernel, one that is turned on by default. If, for whatever reason, you would like to completely disable /proc on your system, de-select /proc file system support within the File system configuration section of config, menuconfig, or xconfig when rebuilding your kernel. Alternatively, you can simply comment out the /proc line in /etc/fstab to prevent it from being mounted. • The /proc virtual files exhibit some interesting qualities. First, most of them are 0 bytes in size. However, when the file is viewed, it likely contains quite a bit of information. In addition, most of their time and date settings reflect the current time and date, meaning that they are constantly changing. • A system administrator can use /proc as an easy method of accessing information about the state of the kernel, the attributes of the machine, the states of individual processes, and more. Most of the files in this directory, such as interrupts, meminfo, mounts, and partitions, provide an up-to-the-moment glimpse of a system's environment.

More Related