CIS c. University of Pennsylvania Zachary Goldberg. Notes

Size: px

Start display at page:

Download "CIS c. University of Pennsylvania Zachary Goldberg. Notes"

Leon Eaton
5 years ago
Views:

1 Notes Root Privileges sudo su Changing system configuration needs root Installing things, like Perl Modules! Intentionally things are owned by root so you don t accidentally break anything! 10/03/09 Slide 1

2 Debugging Common Errors Permission Denied (Do you need to be root? Check directory has +x) File not found (Does it exist? Double check!) Check the logs! 10/03/09 Slide 2

3 Xorg Xorg x11 is the display manager. Configures your display, keyboard, mouse, video card etc. Config file /etc/xorg.conf Log file: /var/log/xorg.#.log # is generally 0 or 1 Hw: Wipe it out and remake it by hand! (No autoconfiguration utilities allowed) Please do this inside virtualbox! 10/03/09 Slide 3

4 The Kernel This has nothing to do with popcorn. I'm sorry. 10/03/09 Slide 4

5 The 'Other' Guy We must first establish that when you write a piece of code and run it that there is something bigger than you going on. There is an operating system controlling things. But what does that mean? 10/03/09 Slide 5

6 Spaces Kernel Space User Space God's code Your code Drivers / Hardware / Memory / Processing related Accesses the hardware for you. Normal programs you run. Limited access to the underlying hardware. e.g. Emacs e.g. Scheduler, network driver 10/03/09 Slide 6

7 A Stack Grey = Hardware Vendor Red = Kernel Code Blue = Userspace Userspace Code Kernel Exposed API Abstraction Kernel Interface Layer DRIVER FIRMWARE HARDWARE 10/03/09 Slide 7

8 Hardware Physical circuity which takes input signals from other parts of the machine, processes it somehow and produces output. Examples: Central Processing Unit (CPU), Hard Drives, Random Access Memory (RAM), Graphics Processing Unit(s) (GPU) Can only be updated by buying new equipment 10/03/09 Slide 8

9 Firmware Code which is programmed into the hardware to tell it how to run. Produced by hardware manufacturers. Heavily tested (hopefully) before product ships, sensitive code! Rarely updated, often must be done with proprietary utilities. 10/03/09 Slide 9

10 Driver A software layer which communicates in between the hardware and the kernel. Every piece of hardware will need some sort of driver to function. Written by hardware manufacturers and, in Linux's case, often by the kernel community. *Drivers make up a huge percentage of the code of kernel. Thus of course they are also a huge portion of the bugs. Most system crashes in all operating systems are due to buggy drivers. 10/03/09 Slide 10

11 Driver to Kernel Layer Every driver must communicate with a standard layer for its category in the kernel. e.g. All network drivers provide the same network interface API. So when the kernel wants to send a network packet it always is the same API call, just to a different driver. 10/03/09 Slide 11

12 Exposed Kernel APIs When userspace wants to interact with the hardware it has to tell the kernel to do it. Userspace code does not have access to raw hardware. It must talk through the kernel! 10/03/09 Slide 12

13 Userspace code Any Normal Program that you run Or that you write... 10/03/09 Slide 13

14 An example : Typing 'a' in bash How does a keystroke of the letter a go from your keyboard to showing up in the terminal?` 10/03/09 Slide 14

15 Keystroke example 1 : keyboard driver The keyboard sends a signal to an I/O controller on your motherboard. The controller then sends an interrupt (IRQ) to the CPU, which jumps to a certain place in the kernel where it knows how to handle keyboard events (driver code). 10/03/09 Slide 15

16 Kernel > passing the message up The kernel will then look for all userspace code which has previously asked the kernel to listen for keyboard events. In this case, the X Server will be listening for the keypress. X will then look for what window is currently in focus. X then tells that program that a keypress happened. 10/03/09 Slide 16

17 What the terminal does Terminal then passes the message over to bash Bash then figures out that it needs to display the character. Bash then says print 'a'. 10/03/09 Slide 17

18 print a This call then jumps through a couple more hoops and eventually hits the X server. X then looks for the appropriate font to figure out what 'a' looks like. X then sends a message to the kernel to change handful of pixels on the screen, in the right order to be an 'a' and in the right location in bash. 10/03/09 Slide 18

19 Messaging going back down to the kernel The kernel then receives the video request. Kernel passes the message to the video driver. Video driver then processes the information, puts it into the framebuffer. 10/03/09 Slide 19

20 Displaying When the next framebuffer call happens (milliseconds later) the video card hardware displays a new image on the screen, including the new pixels which represent an 'a'. Thats it! Simple, no? 10/03/09 Slide 20

21 Flow Chart Keypress 'a' Motherboard CPU Interrupt Kernel Driver Bash Terminal X Server X Server Kernel / Userspace API Kernel Graphics API Video Driver Kernel KeyEvent API Kernel / Userspace API Display 'a' 10/03/09 Slide 21

22 The Linux Kernel Developed initially by Linux Torvalds First release in 1991 Open source thousands of contributors since '91. Monolothic Design One kernel entity. Slightly less fancy than the micro kernel approach. Slightly bigger because of that. But it works really well. 10/03/09 Slide 22

23 Statistics March 1994, Linux (176,250 lines of code) March 1995, Linux (310,950 lines of code) December 2003 Linux (5,929,913 LOC). December 2008 Linux (10,195,402 LOC) 10 MILLION lines of code! Surely we don t use all of that at once... 10/03/09 Slide 23

24 Modules Over the years the Linux Kernel has developed to be more and more modular. Thousands of individual 'on/off' options in the kernel. Every driver is shipped with the kernel. To 'install a driver' you just flip the switch to on and enable the driver's module. You could also build the driver directly into the kernel. 10/03/09 Slide 24

25 Configuring a kernel /usr/src/linux # make menuconfig From there you'll have an entire menu system presented inside the console. 'Y' means built in 'M' means build as module (can be pluged in and out) 'N' means don't build. 10/03/09 Slide 25

26 Building a kernel /usr/src/linux # make && make modules_install This will process the (many) Linux 'Makefiles' (later) Based on your entered configuration build the needed parts of your kernel. 10/03/09 Slide 26

27 Using the new kernel If you've built a wholly new kernel you need to switch kernels. New, very complex, techniques to switch Linux Kernels WHILE THE MACHINE IS RUNNING! Or just copy the new kernel and reboot (something like:) /usr/src/linux # cp arch/x86/boot/bzimage /boot/bzimage 10/03/09 Slide 27

28 Using the new kernel What if we only added a new module? We want to use that module. But how? 3 commands: modprobe lsmod rmmod 10/03/09 Slide 28

29 modprobe # modprobe usbhid modprobe talks to the Kernel and tells it to look (in standard locations) for a module called 'usbhid'. If found 'usbhid' is loaded into the kernel as if it were built in. If 'usbhid' is a device driver then that driver will begin looking for devices and reporting them. 10/03/09 Slide 29

30 An aside: dmesg The Linux Kernel has a lot of debugging output that can be very useful. 'display message' root@localhost # dmesg Dumps kernel output buffer If modprobe fails (incompatible driver etc.) the end of dmesg will have reasons as to why. Very useful for debugging general kernel issues. 10/03/09 Slide 30

31 rmmod # rmmod usbhid To take a module out of the kernel you 'remove module'. Modules have a dependency hierarchy. You cannot load a USB Sound Card driver without the generic USB driver. Thus you need to remove all modules depending on a certain module first. But how do you know what depends on a module? 10/03/09 Slide 31

32 lsmod # lsmod 'list modules'. Will print out a list of currently loaded modules, the amount of memory they're using and any other modules depending on them. 10/03/09 Slide 32

Pico Computing. M 501 / M 503 Getting Started Guide. March 7, Overview 1. 2 System Requirements 1. 3 Ubuntu Linux Configuration 2

Pico Computing. M 501 / M 503 Getting Started Guide. March 7, Overview 1. 2 System Requirements 1. 3 Ubuntu Linux Configuration 2 Pico Computing M 501 / M 503 Getting Started Guide March 7, 2012 Contents 1 Overview 1 2 System Requirements 1 3 Ubuntu Linux Configuration 2 4 Installing the Pico Software 4 5 Monitoring Cards With purty