% 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} 
