컴퓨터 시스템 설계 및 실험

1. 컴퓨터 시스템설계 및 실험 Ch.3 Embedded Linux System

2. Windows vs. Linux Winamp Internet Explorer Mozilla Xmms Outlook Express Kmail 리눅스용 한글 2002 한글2002 Windows Media Player Mplayer

3. Embedded System Monitoring, Control, Remote Management, Consumer Devices Applications Databases, Graphics, Java Middleware Linux, VxWorks, others... Operating System PPC, 68k, MIPS, ARM, x86, etc. CPU/ASIC • SoC • CPU + ASIC + Software • Traditional application-specific systems • Implemented by algorithm-to-architecture methodology. • Modern Trend • Applications of the embedded systems become more complex. • Design Reuse • Software plays an important role. • Real-time operating systems ( RTOS ) is the critical component.

4. Embedded System • A new system-level synthesis flow Compilation Algorithm Development Process Management System Design Interprocess Communication RTOS Memory Management I/O Management Architecture IC Design

5. Embedded System • Embedded System Characteristics • Change many of the assumptions underlying conventional computer system design • Resource limitations • No hard disk, small memory, battery-operated, low performance CPU, … • Real-time characteristics • Real-time system requires finer resolution time keeping and execution time prediction because they must control when actions occur • Precise control of events on real-time line • Execution time predictions are required in many cases • Application-specific and often special purpose • Application semantics differ widely • Sometimes, single user, single application but with multiple external interactions • Majority of all computers (80%+) are embedded • Increasing number must satisfy real-time constraints

6. Embedded/Real-Time OS • According to Japan ITRON survey in 1998 • 75% of embedded systems use operating systems • 95% of embedded systems with program size larger than 1 MB employ operating systems => System software such as operating systems and middleware are must for complex and sophisticated embedded systems • Real-Time System OS Characteristic • Hardware abstraction • Common to all operating systems • Without this, to print “Hello, World.” in a display, application programmers must code for video card initialization, memory management, and video card manipulation. • Multitasking: concurrency management • Handle multiple task with independent events and action • Task create, schedule, execute, terminate and destroy • Support for context save and restore • Task execution image: task code, data segment, stack, heap • Segment table, page table, file descriptors, and file tables • Hardware register context: CPU registers

7. Real-Time OS ISR scheduling ISR iret Task1 Task2 Task1 Scheduling latency Response time of Task2 Interrupt latency • Predictable latency guarantee for context switching • A real-time OS must meet the following conditions • Fully preemptible kernel • Priority-based scheduling • Both fully preemptible and priority-based scheduling are required to assign CPU to an important task with hard deadline • Bounded delay for interrupt latency • Bounded delay for scheduling latency

8. Linux as a Real-time OS • Why Linux for Embedded system? • Main characteristics • Multi-processor, multi-thread, multi-tasking • Multi-user support • Dynamic modules • Support for different file system (ext2, ..) • Networking (TCP/IP, SLIP, PPP) • Support various architecture (X86, Sparc, ARM, MIPS, Alpha, SuperH, PowerPC ..) • SMP support • Key attractions • Free: no license fee • Open source: • Direct access to source codes allow several optimizations and functional additions which are not possible in commercial OS • Support from many individual programmers • Reliability, scalability, portability, standardization

9. Linux as a Real-time OS • Why Linux for Embedded system? • Drawbacks • Monolithic kernel (performance-oriented) • Not for beginners (for system programmers) • Not well structured (not designed on the drawing board) • Not useful for real-time systems • Non-preemptible kernel • Preemptible scheduling only in user mode, but not in kernel mode • Fairness scheduling, with limited priority scheduling • Throughput-oriented nature from PCs and servers • Unpredictable, sometimes high latency • No bounded delay guarantee for interrupt latency as well as scheduling latency • Non-deterministic behavior • Coarse timing resolution

10. Linux as a Real-time OS • Real-Time Linux • Modifications or extensions to standard Linux to allow soft or hard real-time applications to meet timing constraints. • Three approaches: both open source and commercial versions • Dual-kernel approach • One approach uses a separate real-time “kernel” that runs Linux as the lowest priority task. • No modification of Linux kernel • RT Linux (FSMLabs, 1995), RTAI (DIAPM) • Preemption point insertion approach • Insert preemption point (rescheduling routine) to all the locations that may cause long delay inside the kernel • This rescheduling routine inspects whether there is any higher-priority task pending • Low latency patch (Ingo Molnar, Andrew Morton) • Fully preemptible kernel approach • Another approach modifies standard Linux for preemptibility, latency, timing, and/or scheduling. • Montavista Linux

11. Linux as a Real-time OS • Dual Kernel Approach • RTLinux and RTAI • Standard Linux becomes the lowest priority task for the real-time kernel (microkernel) • All real-time processes are run on the microkernel while non real-time processes such as editor and GUI are run on the standard Linux kernel • Benefits • No modifications of the Linux kernel • Ultra low-latency interrupts and context switches (5 - 10 mSecs) • Guaranteed, deterministic scheduling

12. Linux as a Real-time OS • Dual Kernel Approach • Limitations • All real-time features must be implemented as kernel modules • Real-time application development is much more difficult • Real-time applications cannot utilize system services that are provided by the standard Linux, such as file systems and network support • Must be very knowledgeable of the Linux kernel and device driver interaction • No memory-protection available • Improper coding will crash the kernel • More difficult to debug, lack of easy-to-use tools • Linux system calls are not preemptible and performance cannot be guaranteed

13. Linux as a Real-time OS • A "fully" preemptible Linux kernel • Allows the kernel to be preempted at any time when it is not locked • This is supported by SMP lock and unlock • All the data structures used by the kernel are protected by the SMP lock/unlock mechanism when more than one processes are executed in the kernel mode. • Benefits • Real-time application development is much easier • Memory protection is available • Real-time programs will not crash the kernel • Full access to system services (TCP/IP, file I/O, X-Windows, etc.) • Extensive tool support for easier debugging

14. Linux as a Real-time OS • A "fully" preemptible Linux kernel • Limitations • Performance may not be good enough for low-latency requirements in the microseconds • Worst-case interrupt latency is unknown since all possible code paths have not been tested • Reduced overall system throughput • Substantial source code modification is made to the kernel • Extensive testing is needed with every new release of the kernel • Preemptibility analysis required with all device drivers and kernel modules

15. Linux Kernel User Space process 1 process 2 process 3 process n System Call Interface Filesystem Manager Process Manager Task Management Scheduler Signaling IPC Ext2fs proc xiafs nfs msdos ntfs Memory Manager Paging/Segmentation Kernel Space Buffer Cache Device Manager Network Manager character block socket Ipv6 IrDA Bluetooth Console KBD SCSI CD-ROM PCI ethernet Hardware Interface dev1 dev2 dev3 dev4 devn • Linux Kernel Architecture

16. Linux Kernel ipc lib kernel mm scripts block Doc cdrom /usr/src/linux driver char arch alpha net fs net init include 802 pci arm asm-alpha appletalk coda pnp m68k asm-arm decnet sbus ext2 mips ... ethernet scsi hpfs ppc boot asm-i386 sound ipv4 msdos sparc kernel video unix linux nfs i386 lib ... sunrpc isofs net math-emu x25 minix scsi ... ... mm video • Linux Source Tree

17. Linux Kernel • Main subdirectory (relative pathname to /usr/src/linux) • arch/ • Architecture dependent codes : arch/i386, arch/alpha, …. • arch/i386/boot/ • bootstrapping • configure devices, memory, and machine specific modules • arch/i386/kernel/ • kernel entry point handling (trap/interrupt handling) • context switch • arch/i386/mm/ • machine dependent memory management code • init/ • All the functions needed to start the kernel (start_kernel) • Hand-made process 0 (init_task or task[0]) • Fork process 1, 2, 3, ...

18. Linux Kernel • Main subdirectory • kernel/ (arch/i386/kernel) • Central section of the kernel • All the routines related to task management such as process creation, termination, execution, scheduling, signal handling, etc. • Main system call implementation (fork, exit, etc.) • Time management • Scheduler • Signal handling • mm/ • Virtual memory interface • Paging, kernel memory management • fs/ • Virtual file system interface • Implementations of the various file systems (ext2, proc, nfs,...)

19. Linux Kernel • Main subdirectory • drivers/ • Device drivers for hardware components • drivers/block/ : block-oriented driver(hard disks) • drivers/cdrom/ : proprietary CD-ROM drives • drivers/char/ : character-oriented driver (serial ports, tty, modem, ..) • drivers/net : network cards • drivers/pci/ : PCI bus access and control • drivers/scsi/ : SCSI interface • drivers/sound/ : sound card drivers • ipc/ • Classical inter-process communication • Semaphores, message queues

20. Linux Kernel • Main subdirectory • net/ • Various network protocol implementations : TCP/IP, ARP, ... • Code for sockets to the UNIX and Internet domains • lib/ • Some standard kernel library functions (printk) • include/ • Commonly included kernel-specific header files • include/asm-i386/ : architecture-dependent header files for Intel CPU • include/linux/ : Linux kernel internal structure (task, inode)

21. Linux Kernel • Kernel Configuration and Compile • New kernel is generated in three steps • Kernel configuration (see Documentation/Configuration.help or chapter 3 of “The LINUX Network”) • make config (menuconfig, xconfig) • Informs Linux kernel of hardware characteristics, kernel components, network characteristics that exist in the system • Kernel compile • make dep (make clean) • Checks dependencies among source files • make bzImage • Compile and generate executable kernel image • Kernel installation (module installation and inform LILO (Linux loader) of the new kernel location • To be able to boot the system from the new kernel • make modules • make modules_install • cp arch/i386/boot/bzimage /boot/vmlinx-new • vi /etc/lilo.conf

22. Process Management • What is the process? • An instance of a program in execution • A dynamic and active entity • Program • A passive entity stored as an executable binary image consisting of code and data sections in the non-volatile memory such as HDD • The basic unit of execution and scheduling. • A process is named using its process ID (PID). • Linux process management • Responsible for the following activities in connection with process management • Process creation and deletion • Process state transition • Process context switching • ‘THE’ core component of the Linux Kernel

23. Process Management • Process manager

24. Process Management • Process creation • One process can create another process by calling a system call fork() • Parent-child relationship • Parent may inherit all or a part of resources and privileges for its children • Child duplicates the parent’s address space or has a program loaded into it. • All the processes are created by calling a fork() from a parent process except pid 0 which is created by the kernel during system initialization • This pid 0 forks init process (pid 1) and kflushd process (pid 2) using the fork system call • Execution • A newly created process can be executed by calling a system call execve() • Parent process may either wait for it to finish, or it may continue in parallel.

25. Process Management • Process termination • Voluntary • Normal exit • Process finished its execution • Error exit • Involuntary • Fatal error • Exceed allocated resources • Segmentation fault • Protection fault, etc. • Killed by another process • By receiving a signal

26. Process State and Transition running exit initial zombie wait fork dispatch sleep fork timeout ready waiting wakeup • Running • Executing on CPU • Ready • Ready to be executed (on a timeout or from a wakeup) • Waiting on a run queue • Waiting • Waiting until a specific event occurs (by either a sleep or lock request, or IO request) • Zombie • Process execution is terminated (on exit) • Returned all the resources and exist to provide only statistics to its parent

27. Process Information • Process’s context • task_struct in Linux • Each task_structcontains all the information about a process. • Task structure • Identifier: pid, pgrp, session, leader… • State: TASK_RUNNING, TASK_ZOMBIE... • Process relationship: p_opptr, p_pptr, p_yptr… • Scheduling information : policy, priority, counter, rt_priority, need_resched • Signal information :signal_struct , sigpendign, signal , blocked • Memory information : page table (address translation, access information, privilege information, etc) • Files information: fs, files, .. (file descriptors and file tables) • Time information: start_time, execution time in user/kernel mode, ... • Resource limits • Task’s binary executable image • Text, static global data, heap, stack • Hardware register context • PC, general-purpose registers

28. Process Scheduling • Linux uses two process-scheduling algorithms • Real-time scheduling for tasks where absolute priorities are more important than fairness • Time-sharing based scheduling for fair preemptive scheduling between multiple processes • Real-time scheduling • Linux implements the FIFO and round-robin real-time scheduling classes • The scheduler selects the process with the highest priority • SCHED_FIFO • For equal-priority nonpreemptive processes • The scheduler selects the longest-waiting one • SCHED_RR • For preemptive processes • The scheduler preempts the currently running process when a higher-priority (higher value of rt_priority) process appears • Time-sharing scheduling • SCHED_OTHER: Time sharing scheduling for non-real time processes

29. Linux file systems • Linux file systems • To the user • Linux file system appears as a hierarchical directory tree • Linux file system sees a hard disk as a set of logical disk blocks • Linux file appears as a storage for a stream of bytes • History • Linux file system first uses the Minix file system (1991) • Max. file size : 64MB, max. file name : 14 characters • Ext: The first native Linux file system (1992) • Ext2: The second version of native Linux file system (1993) • The virtual file system (VFS) • Provide an interface between Linux OS and actual file systems used • Linux VFS can support different file systems (i.e. different file formats) used in different computer systems • The Linux VFS is designed around object-oriented principles • A set of definitions • The inode-object and the file-object structures represent individual files • The file system object represents an entire file system • A layer of software to manipulate those objects.

30. Linux File Systems • Disk-based file systems • Ext2: Linux native • Ufs : BSD • Fat: DOS FS • Vfat: Win95 • minix : the first file system of Linux • Iso9660: CD-ROM • Sysv: System V • Hfs: Macintosh • Affs: Amiga • Ntfs: NT’s FS • Adfs: Acorn-strongarm • Network file systems • Nfs: • Coda: • afs: Andrew FS • Smbfs: LanManager • Ncpfs: Novell • Special ones • Procfs: process state information for ps • Umsdos – Unix in DOS • Userfs – redirector to user

31. Linux file systems User process User process User process User mode Virtual File System Switch kernel mode Ext2 msdos minix proc Buffer cache Device driver Disk Disk • Linux file systems

32. Linux file systems • inode structure • inode • Information about each file • A file has its inode • inode information • The type of the file (i_mode) • regular, directory, block special, character special, etc • File access permissions • The file seze (i_size) • The owner and group ids (i_uid, i_gid) • The creation, last modification and last access times (i_ctime, i_mtime, i_atime) • Device numbers for special file • The number of the symbolic links pointing to this file • The location of blocks (index block) • Non-contiguous block allocation for a file • 3 direct block addresses • 12 indirect block addresses • Assuming 4B pointer and 4KB block, it can support a file size up to 48KB + 4MB + 4GB + 4TB

33. Linux file systems inode i_inode_number i_mode i_nlink, i_dev i_uid, gid i_op i_atime, ctime, mtime 12 direct block …. 3 indirect block • inode structure 2 1 3 S_IFSOCK S_IFLNK S_IFREG S_IFBLK S_IFDIR S_IFCHR S_IFIFO read/write/execution 1 : users 2 : group 3 : other users u : set user id g : set group id s : sticky

34. Linux file systems • The Virtual File System (VFS) • Present a uniform interface to user processes regardless of the actual file system used • System calls sent to the VFS • VFS references a driver for the actual file system on that partition • File system driver uses the disk cache • 3 main objects • Superblock object • Information about the entire file system mounted • Inode object • All the necessary information about a file • File object • Information regarding the interaction between a process and files opened

35. Linux file systems • A Logical Diagram of the Virtual File System User space Inode Cache VFS Directory Cache NTFS CryptFS Ext2 Buffer Cache Maintained by the kernel Disk Drivers

36. Linux file systems • Mounting an FS • To use a FS • You need to mount it • This is the process of telling the VFS enough information to create the VFS superblock • Performance differences occur in this area • Ext2 has similar structure to VFS and is very popular • Other FS need to “map” their structure to elements VFS can understand • If a certain block device cannot supply this information, or if support is not in the kernel, the mount fails.

37. Linux Device Drivers • Device drivers • Intended to control a peripheral device • Has interfaces both to the file system and to device hardware • Provides an abstraction to physical hardware devices • Characteristics of Linux device drivers • An essential part of a Linux kernel • Must be integrated into the OS kernel • A bad device driver can corrupt or destroy the entire system • Loadable • Implemented as a kernel module • Loaded when necessary and unloaded if not • Configurable • Can be included or excluded at compile time

38. Linux Device Drivers • Types of device drivers • Character device drivers • Process individual bytes and transmit data of any arbitrary size • Process sequentially (Terminal, Keyboard, Sound Card, Scanner, Printer , Network Card) • Block device drivers • Random access and transmit data in blocks • Accesses are handled transparently by the buffer cache • Process groups of bytes, i.e. (blocks)(hard disks, CD-ROM drives, …) • Network device drivers

39. Linux Device Drivers # mknod /dev/nametype major minor Minor number Major number b(block) or c(character) Device Name • Major & Minor Number • Link to the device • 1Byte each • Major • Identifies the driver associated with the device • Indexes blkdevs[] or chrdevs[] • Minor • Only used by the device driver • Indexes tables within the driver to identify the virtual device

40. Linux Device Drivers Major Character devices Block devices 0 unnamed for NFS, network and so on 1 Memory device(mem) RAM disk 2 Floppy disks(fd*) 3 IDE hard disks(hd*) 4 Terminals 5 Terminals & AUX 6 Parallel Interfaces 7 Virtual Consoles(vcs*) 8 SCSI hard disks(sd*) 9 SCSI tapes(st*) 10 Bus mice(bm, psaux) 11 SCSI CD-ROM(scd*) 12 QIC02 tape 13 PC Speaker driver XT 8-bit hard disks(xd*) 14 Sound cards BIOS hard disk support 15 Joystick Cdu31a/33a CD-ROM - 19 Cyclades drivers Double compressing driver 20 Cyclades drivers 21 SCSI generic 22 2nd IDE interface driver 23 Mitsumi CD-ROM(mcd*) 24 Sony 535 CD-ROM 25 Matsushita CD-ROM 1 ------ • Linux Major Number List Source code : ~include/linux/major.h

41. Linux Networks • The Linux TCP/IP Networking Layers

42. Linux Networks • The BSD Socket Interface • Linux supports the following socket address families or domains • UNIX • Unix domain sockets • INET • The Internet address family supports communications via TCP/IP • AX25 • Amateur radio X25 • IPX • Novell IPX • APPLETALK • X25

43. Linux Networks • The INET Socket layer • Creating a BSD Socket • Binding an Address to an INET BSD Socket • Making a Connection on an INET BSD Socket • Listening on an INET BSD Socket • Accepting Connection Requests • TCP/UDP layer • Offer two types of service • Transmission Control Protocol (TCP) • Connection-oriented service • All packets will be delivered (flow control) • User datagram Protocol (UDP) • Connectionless service • No guarantee • packets are stored and forwarded one at a time

44. Linux Networks • The IP Layer • IP address (4 bytes) • Socket Buffers • Receiving IP Packets • Sending IP Packets • Data Fragmentation • The Address Resolution Protocol (ARP) • the task of the ARP is to convert the abstract IP address into real hardware addresses.

45. Linux module programming • The motivation of modules • Linux kernel is a monolithic kernel • The limitation of a monolithic kernel • When the configuration is changed, the kernel has to be compiled. • Rarely used file systems and drivers occupy memory permanently. • The kernel code modification results in creating the new kernel and rebooting the system lead to the development of “modules”

46. Linux module programming • What is a module • Linux module • is a functional unit such as file system or driver • can be dynamically linked into the kernel at any point after the system has booted. • can be removed from the kernel when it is no longer needed. • When a module is loaded, it is same as a kernel. • result in small and compact kernel size and the ability of trying • out new kernel code without rebuilding and rebooting the kernel

47. Linux module programming • Module data structure • The loaded modules are maintained by module data structure. • Each module data structure points to the symbol table structure that contains all symbols of the module. • The kernel keeps all of the kernel’s resources in the kernel symbol table • the loaded modules are able to use all kernel resources. • The kernel symbol table is pointed the first module data structure.

48. Linux module programming module module_list module next next ref ref symtab symtab “kernel symbol table module” “sysv module” size size references references kernel symbol table sysv symbol table • The list of kernel modules

49. Linux module programming • Loading a module • Manual way • Using ‘insmod’ command. • automatic way • the kernel discovers the need for loading a module (for example, user mounts a file system) • requests ‘kerneld’ daemon to load the needed module. • ‘kerneld’ loads module using insmod.

50. Linux module programming • The ‘insmod’ mechanism • Reading the module into its virtual memory • Fixes up unresolved references to kernel routines and resources using the exported symbols from the kernel. • Requests the kernel for enough space to hold the new kernel • The kernel • Allocates a new module data structure • Allocates enough kernel memory to hold the new module • Puts it at the end of the kernel modules list