[FE training-materials-updates] kernel: fix build, reorganize versioning slides
Thomas Petazzoni
thomas.petazzoni at free-electrons.com
Tue Oct 1 15:40:38 CEST 2013
Repository : git://git.free-electrons.com/training-materials.git
On branch : kernel-ng
Link : http://git.free-electrons.com/training-materials/commit/?id=da463004e2a85cc8dbe4ed20608c4e34a1decccf
>---------------------------------------------------------------
commit da463004e2a85cc8dbe4ed20608c4e34a1decccf
Author: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Date: Tue Oct 1 15:40:11 2013 +0200
kernel: fix build, reorganize versioning slides
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
>---------------------------------------------------------------
da463004e2a85cc8dbe4ed20608c4e34a1decccf
Makefile | 4 +-
slides/kernel-contribution/kernel-contribution.tex | 88 ++++++++
.../kernel-development-process-title.tex | 2 +
.../kernel-development-process.tex | 235 --------------------
4 files changed, 93 insertions(+), 236 deletions(-)
diff --git a/Makefile b/Makefile
index 5280e27..4561ef4 100644
--- a/Makefile
+++ b/Makefile
@@ -60,7 +60,9 @@ KERNEL_SLIDES = \
kernel-power-management-title \
kernel-power-management-content \
kernel-power-management-lab \
- kernel-development-process \
+ kernel-development-process-title \
+ sysdev-linux-intro-versioning \
+ kernel-contribution \
kernel-resources-title \
kernel-resources-references \
last-slides
diff --git a/slides/kernel-contribution/kernel-contribution.tex b/slides/kernel-contribution/kernel-contribution.tex
new file mode 100644
index 0000000..6e843db
--- /dev/null
+++ b/slides/kernel-contribution/kernel-contribution.tex
@@ -0,0 +1,88 @@
+\subsection{Contributing to the Linux kernel}
+
+\begin{frame}
+ \frametitle{Solving Issues}
+ \begin{itemize}
+ \item If you face an issue, and it doesn't look specific to your
+ work but rather to the tools you are using, it is very likely that
+ someone else already faced it.
+ \item Search the Internet for similar error reports.
+ \item You have great chances of finding a solution or workaround, or
+ at least an explanation for your issue.
+ \item Otherwise, reporting the issue is up to you!
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Getting Help}
+ \begin{itemize}
+ \item If you have a support contract, ask your vendor.
+ \item Otherwise, don't hesitate to share your questions and issues
+ \begin{itemize}
+ \item Either contact the Linux mailing list for your architecture
+ (like linux-arm-kernel or linuxsh-dev...).
+ \item Or contact the mailing list for the subsystem you're dealing
+ with (linux-usb-devel, linux-mtd...). Don't ask the maintainer
+ directly!
+ \item Most mailing lists come with a FAQ page. Make sure you read
+ it before contacting the mailing list.
+ \item Useful IRC resources are available too
+ (for example on \url{http://kernelnewbies.org}).
+ \item Refrain from contacting the Linux Kernel mailing list,
+ unless you're an experienced developer and need advice.
+ \end{itemize}
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Reporting Linux Bugs}
+ \begin{itemize}
+ \item First make sure you're using the latest version
+ \item Make sure you investigate the issue as much as you can: see
+ \kerneldoc{BUG-HUNTING}
+ \item Check for previous bugs reports. Use web search engines,
+ accessing public mailing list archives.
+ \item If the subsystem you report a bug on has a mailing list, use
+ it. Otherwise, contact the official maintainer (see the
+ \code{MAINTAINERS} file). Always give as many useful details as
+ possible.
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{How to Become a Kernel Developer?}
+ \begin{itemize}
+ \item Recommended resources
+ \begin{itemize}
+ \item See \kerneldoc{SubmittingPatches} for guidelines
+ and \url{http://kernelnewbies.org/UpstreamMerge} for very
+ helpful advice to have your changes merged upstream (by Rik van
+ Riel).
+ \item Watch the \emph{Write and Submit your first Linux kernel
+ Patch} talk by Greg. K.H:
+ \url{http://www.youtube.com/watch?v=LLBrBBImJt4}
+ \item How to Participate in the Linux Community (by Jonathan
+ Corbet) A Guide To The Kernel Development Process
+ \url{http://j.mp/tX2Ld6}
+ \end{itemize}
+ \end{itemize}
+\end{frame}
+
+
+\begin{frame}
+ \frametitle{How to Submit Patches or Drivers}
+ \begin{itemize}
+ \item Use git to prepare make your changes
+ \item Don't merge patches addressing different issues
+ \item Make sure that your changes compile well, and if possible, run well.
+ \item Run Linux patch checks: \code{scripts/checkpatch.pl}
+ \item Send the patches to yourself first, as an inline
+ attachment. This is required to let people reply to parts of your
+ patches. Make sure your patches still applies. See
+ \kerneldoc{email-clients.txt} for help configuring e-mail
+ clients. Best to use \code{git send-email}, which never corrupts
+ patches.
+ \item Run \code{scripts/get_maintainer.pl} on your patches, to know
+ who you should send them to.
+ \end{itemize}
+\end{frame}
diff --git a/slides/kernel-development-process-title/kernel-development-process-title.tex b/slides/kernel-development-process-title/kernel-development-process-title.tex
new file mode 100644
index 0000000..873579b
--- /dev/null
+++ b/slides/kernel-development-process-title/kernel-development-process-title.tex
@@ -0,0 +1,2 @@
+\section{The kernel development and contribution process}
+
diff --git a/slides/kernel-development-process/kernel-development-process.tex b/slides/kernel-development-process/kernel-development-process.tex
deleted file mode 100644
index b4f496f..0000000
--- a/slides/kernel-development-process/kernel-development-process.tex
+++ /dev/null
@@ -1,235 +0,0 @@
-\subsection{The kernel development and contribution process}
-
-\begin{frame}
- \frametitle{Until 2.6 (1)}
- \begin{itemize}
- \item One stable major branch every 2 or 3 years
- \begin{itemize}
- \item Identified by an even middle number
- \item Examples: \code{1.0.x, 2.0.x, 2.2.x, 2.4.x}
- \end{itemize}
- \item One development branch to integrate new functionalities and
- major changes
- \begin{itemize}
- \item Identified by an odd middle number
- \item Examples: \code{2.1.x, 2.3.x, 2.5.x}
- \item After some time, a development version becomes the new base
- version for the stable branch
- \end{itemize}
- \item Minor releases once in while: \code{2.2.23, 2.5.12}, etc.
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{Until 2.6 (2)}
- \begin{center}
- \includegraphics[width=\textwidth]{slides/sysdev-linux-intro-versioning/old-development-process.pdf}
- \end{center}
-\end{frame}
-
-\begin{frame}
- \frametitle{Changes since Linux 2.6}
- \begin{itemize}
- \item Since \code{2.6.0}, kernel developers have been able to
- introduce lots of new features one by one on a steady pace,
- without having to make major changes in existing subsystems.
- \item So far, there was no need to create a new development branch
- (such as \code{2.7}), which would massively break compatibility
- with the stable branch.
- \item Thanks to this, {\bf more features are released to users at a
- faster pace}.
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{3.x stable branch}
- \begin{itemize}
- \item From 2003 to 2011, the official kernel versions were named \code{2.6.x}.
- \item Linux \code{3.0} was released in July 2011
- \item This is only a change to the numbering scheme
- \begin{itemize}
- \item Official kernel versions are now named \code{3.x}
- (\code{3.0, 3.1, 3.2}, etc.)
- \item Stabilized versions are named \code{3.x.y}
- (\code{3.0.2, 3.4.3}, etc.)
- \item It effectively only removes a digit compared to the previous
- numbering scheme
- \end{itemize}
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{New development model}
- Using merge and bug fixing windows
- \begin{center}
- \includegraphics[width=\textwidth]{slides/sysdev-linux-intro-versioning/new-development-process.pdf}
- \end{center}
-\end{frame}
-
-\begin{frame}
- \frametitle{New development model - Details}
- \begin{itemize}
- \item After the release of a \code{3.x} version (for example),
- a two-weeks merge window opens, during which major additions are merged.
- \item The merge window is closed by the release of test version
- \code{3.(x+1)-rc1}
- \item The bug fixing period opens, for 6 to 10 weeks.
- \item At regular intervals during the bug fixing period,
- \code{3.(x+1)-rcY} test versions are released.
- \item When considered sufficiently stable, kernel \code{3.(x+1)}
- is released, and the process starts again.
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{More stability for the kernel source tree}
- \begin{columns}
- \column{0.7\textwidth}
- \begin{itemize}
- \item Issue: bug and security fixes only released for most recent
- stable kernel versions.
- \item Some people need to have a recent kernel, but with long term
- support for security updates.
- \item You could get long term support from a commercial embedded
- Linux provider.
- \item You could reuse sources for the kernel used in Ubuntu Long
- Term Support releases (5 years of free security updates).
- \item The \url{http://kernel.org} front page shows which
- versions will be supported for some time (up to 2 or 3 years),
- and which ones won't be supported any more ("EOL: End Of Life")
- \end{itemize}
- \column{0.3\textwidth}
- \includegraphics[width=\textwidth]{slides/sysdev-linux-intro-versioning/longterm-versions.png}
- \end{columns}
-\end{frame}
-
-\begin{frame}[fragile]
- \frametitle{What's new in each Linux release?}
- \begin{itemize}
- \item The official list of changes for each Linux release is just a
- huge list of individual patches!
-\Tiny
- \begin{verbatim}
-commit aa6e52a35d388e730f4df0ec2ec48294590cc459
-Author: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
-Date: Wed Jul 13 11:29:17 2011 +0200
-
- at91: at91-ohci: support overcurrent notification
-
- Several USB power switches (AIC1526 or MIC2026) have a digital output
- that is used to notify that an overcurrent situation is taking
- place. This digital outputs are typically connected to GPIO inputs of
- the processor and can be used to be notified of those overcurrent
- situations.
-
- Therefore, we add a new overcurrent_pin[] array in the at91_usbh_data
- structure so that boards can tell the AT91 OHCI driver which pins are
- used for the overcurrent notification, and an overcurrent_supported
- boolean to tell the driver whether overcurrent is supported or not.
-
- The code has been largely borrowed from ohci-da8xx.c and
- ohci-s3c2410.c.
-
- Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
- Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
-\end{verbatim}
-\normalsize
- \begin{itemize}
- \item Very difficult to find out the key changes and to get the
- global picture out of individual changes.
- \end{itemize}
- \item Fortunately, there are some useful resources available
- \begin{itemize}
- \item \url{http://wiki.kernelnewbies.org/LinuxChanges}
- \item \url{http://lwn.net}
- \item \url{http://linuxfr.org}, for French readers
- \end{itemize}
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{Solving Issues}
- \begin{itemize}
- \item If you face an issue, and it doesn't look specific to your
- work but rather to the tools you are using, it is very likely that
- someone else already faced it.
- \item Search the Internet for similar error reports.
- \item You have great chances of finding a solution or workaround, or
- at least an explanation for your issue.
- \item Otherwise, reporting the issue is up to you!
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{Getting Help}
- \begin{itemize}
- \item If you have a support contract, ask your vendor.
- \item Otherwise, don't hesitate to share your questions and issues
- \begin{itemize}
- \item Either contact the Linux mailing list for your architecture
- (like linux-arm-kernel or linuxsh-dev...).
- \item Or contact the mailing list for the subsystem you're dealing
- with (linux-usb-devel, linux-mtd...). Don't ask the maintainer
- directly!
- \item Most mailing lists come with a FAQ page. Make sure you read
- it before contacting the mailing list.
- \item Useful IRC resources are available too
- (for example on \url{http://kernelnewbies.org}).
- \item Refrain from contacting the Linux Kernel mailing list,
- unless you're an experienced developer and need advice.
- \end{itemize}
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{Reporting Linux Bugs}
- \begin{itemize}
- \item First make sure you're using the latest version
- \item Make sure you investigate the issue as much as you can: see
- \kerneldoc{BUG-HUNTING}
- \item Check for previous bugs reports. Use web search engines,
- accessing public mailing list archives.
- \item If the subsystem you report a bug on has a mailing list, use
- it. Otherwise, contact the official maintainer (see the
- \code{MAINTAINERS} file). Always give as many useful details as
- possible.
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{How to Become a Kernel Developer?}
- \begin{itemize}
- \item Recommended resources
- \begin{itemize}
- \item See \kerneldoc{SubmittingPatches} for guidelines
- and \url{http://kernelnewbies.org/UpstreamMerge} for very
- helpful advice to have your changes merged upstream (by Rik van
- Riel).
- \item Watch the \emph{Write and Submit your first Linux kernel
- Patch} talk by Greg. K.H:
- \url{http://www.youtube.com/watch?v=LLBrBBImJt4}
- \item How to Participate in the Linux Community (by Jonathan
- Corbet) A Guide To The Kernel Development Process
- \url{http://j.mp/tX2Ld6}
- \end{itemize}
- \end{itemize}
-\end{frame}
-
-
-\begin{frame}
- \frametitle{How to Submit Patches or Drivers}
- \begin{itemize}
- \item Use git to prepare make your changes
- \item Don't merge patches addressing different issues
- \item Make sure that your changes compile well, and if possible, run well.
- \item Run Linux patch checks: \code{scripts/checkpatch.pl}
- \item Send the patches to yourself first, as an inline
- attachment. This is required to let people reply to parts of your
- patches. Make sure your patches still applies. See
- \kerneldoc{email-clients.txt} for help configuring e-mail
- clients. Best to use \code{git send-email}, which never corrupts
- patches.
- \item Run \code{scripts/get_maintainer.pl} on your patches, to know
- who you should send them to.
- \end{itemize}
-\end{frame}
More information about the training-materials-updates
mailing list