% CVSId: $Id: things.tex,v 1.1 2004/03/22 21:24:58 muli Exp $ \documentclass[final, total, pdf, colorBG, slideColor]{prosper} \title{10 Things Every Linux Programmer Should Know} \subtitle{Linux Misconceptions in 30 Minutes} \author{Muli Ben-Yehuda} \email{mulix@mulix.org} \institution{IBM Haifa Research Labs} \slideCaption{Linux Kernel Workshop, March 2004} \begin{document} \maketitle \begin{slide}{TOC} \begin{itemize} \item What this talk is about \item User space vs. kernel space \item Memory allocation \item Processes vs. threads \item NPTL - Native POSIX Threads Library \item Optimization \item Use the right abstraction layer for the job \item Why coding style is important \item Why you should always check for errors \item The real cost of software development \item Portability \end{itemize} \end{slide} \begin{slide}{What this talk is about} \begin{itemize} \item This talk is about common misconceptions, and things I think every Linux programmer should know. \item This talk is about learning from other people's experience and mistakes. \item This talk is about how to write better software. \item It's about knowing how things work; Knowing how things work lets us embrace and extend Linux. \end{itemize} This talk represents my opinions, and mine only. Feel free to disagree\dots \end{slide} \begin{slide}{User space vs. kernel space} \begin{itemize} \item A process is executing either in user space, or in kernel space. Depending on which priviledges, address space and address (EIP) a process is executing in, we say that it is either in user space, or kernel space. \item When executing in user space, a process has normal priviledges and can and can't do certain things. When executing in kernel space, a process has every priviledge, and can do anything. \item Processes switch between user space and kernel space using system calls. \item Note that there are exceptions and mixed cases, such as processes using iopl(). The biggest difference between user space and kernel space is conceptual - the programmer's state of mind. \end{itemize} \end{slide} \begin{slide}{Memory Allocation} \begin{itemize} \item {\em malloc} is a library function, implemented in the standard C library. It is {\bf not} a system call. \item {\em malloc} is implemented by two means in Linux. The first is the {\em brk()} system call, which grows a process's data segment. The second is mapping /dev/zero to get anonymous memory. In both cases, the end result is the same. \item The kernel allocates a virtual memory area for the application, but does {\em not} allocate physical memory for it. Only when the area is accessed physical memory is allocated. This is known as ``memory overcommit'', and there are ways to disable it. \item Do you really need your own malloc implementation? \item Is {\em malloc()} really too slow for you? \end{itemize} \end{slide} \begin{slide}{Processes vs. threads} \begin{itemize} \item In Linux, processes and threads are almost the same. The major difference is that threads share the same virtual memory address space. \item The low level interface to create threads is the {\em clone()} system call. The higher level interface is {\em pthread\_create()}. \item Context switches between processes in Linux are fast. Context switches between threads are even faster. \item Which is better, multi process or multi threaded? {\bf depends}. \item Linux threading is ``1-1'', not ``1-N'' or ``M-N''. \item Linux threading libraries evolution: Linux Threads, NGPT, NPTL. The library is part of gilbc, programmer interface is POSIX pthreads. \end{itemize} \end{slide} \begin{slide}{NPTL - Native POSIX Threads Library} The New POSIX Threads Library, written by Ulrich Drepper and Ingo Molnar of Red Hat, Inc. \begin{itemize} \item Addresses shortcomings in the design and implementation of Linux Threads. \item Makes use of improved Linux kernel code and facilities. In places, the changes were written specifically for NPTL. \item Uses the newly added Futexes (Fast User space Mutexes). \item Standard in kernel 2.5 and up, and back ported to 2.4 by Red Hat. \item For more information, http://people.redhat.com/drepper/nptl-design.pdf \end{itemize} \end{slide} \begin{slide}{Optimization} \begin{itemize} \item Knuth: "Premature optimization is the root of all evil". \item Avoid the desire to optimize prematurely; concentrate on getting it working {\it first}. \item When it's time to optimize, profile, profile, profile. The desire to ``search for the coin under the streetlight'' is strong, and must be resisted. \item Optimize algorithms first, implementation second. \item There's (almost) no excuse for assembly. \item Decide how fast is fast enough. \item Optimize the system before components. \item Never forget you are not running alone. There are libraries, background processes, the kernel, the CPU and the peripherals. \end{itemize} \end{slide} \begin{slide}{Use the right abstraction layer} \begin{itemize} \item Use the right language for the job. \item Use the right tools for the job. \item Should you be writing in a high level language, low level language, object oriented, functional, logic programming or procedural language? which can express the problem domain best? \item Balance between the desire to learn new tools and techniques and the need to deliver on time and on budget. \item Make sure you have several hammers, but don't disdain a hammer just because you've already used it. \item perl::open(), fopen(), open() or int 0x80? \end{itemize} \end{slide} \begin{slide}{Why coding style is important} \begin{itemize} \item Your code does not belong to you. Someone will be maintaining and extending it long after you are gone. \item Many eyes make all bugs shallow, but if no one can understand your code, no one will look at it. \item There's plenty of room for personal expression even when using someone else's coding style. \item Avoid Hungarian notation. Leave the compiler's job to the compiler. \item Read Documentation/CodingStyle. Burn it if you want, but follow it. \end{itemize} \end{slide} \begin{slide}{Why you should always check for errors} \begin{itemize} \item Anything that can go wrong, will. It's your responsibility to do the best job you can, and that includes handling errors. It's the thing you don't expect to fail that will. \item If there's nothing to be done when an error occures, your design is probably wrong. Nevertheless, leave a comment for the next programmer to read the code. \item The distance between an unchecked error and a security hole is very short. \item Always have sanity checks - you want to catch the error as close as possible to where it occures. \item Check printf() and close(). Be very wary of any string function that doesn't take an explicit length parameter. \end{itemize} \end{slide} \begin{slide}{The real cost of software development} \begin{itemize} \item Maintenance costs far more than development. \item How often have people go on using that ten liner script you wrote year ago? how often did it become ``production''? ``mission critical''? \item There's nothing more permanent than the temporary. Throw away code never is. \item Always write code with an eye to the people who will read it after you. A few years later it might be you, and you'll appreciate every comment you left. \item Write for people, not compilers or processors. \end{itemize} \end{slide} \begin{slide}{Portability} \begin{itemize} \item Portability doesn't cost you, within reason, and can save you time, money and effort down the line. \item Today's platform is tomorrow's garbage. Platforms and operating environments change, and your code must change with them. \item Prefer cross platform toolkits and environments. \item If you must do something platform-specific, abstract it well in its own interchangeable component. \item Avoid multiple portability layers - a good one is enough. \item Don't try to abstract that which is inherently different. \end{itemize} \end{slide} \begin{slide}{Questions, Answers, Comments?} What do {\bf you} think every Linux programmer should know? \end{slide} \end{document}