path: root/index.txt

Linux Kernelprogrammierung - Somersemester 2012 - HS Ravensburg-Weingarten

https://www.youtube.com/watch?v=yVpbFMhOAwE

Organisatorisch
^^^^^^^^^^^^^^^

weitere Termine
===============

30.3  - 1. Vorlesung
13.4  - 2. Vorlesung
20.4  - 3. Vorlesung
27.4  - ==>> 4. Vorlesung <<== Termin entfällt

4.5   - 4. Vorlesung
11.5  - 5. Vorlesung

18.5  - Brueckentag (Christi Himmelfahrt)

8.6   - Brueckentag (Christi Himmelfahrt)
15.6  - 6. Vorlesung
22.6
29.6  - Vortrag von einem Kernelmaintainer + Pruefungsvorbereitung (freiwillig)


Linuxtag:
=========

Mi 23. - Sa 26. Mai Messe Berlin

http://www.winters-hotel-berlin-city-messe.de/
Uebernachtung ca. 100 pro Person

Nach Berlin mit Nachtzug ab Dienstag Abend ca. 21 Uhr
Zurueck Sonntag Nachmittag                           ~100 EUR pro Person

Eintritt: Sponsoren

Zuschuss durch Studiengebuehren, Erfahrungsgemaess ca. 20%.

--> Kosten ca. 180 EUR + Verpflegung und Nahverkehr in Berlin


TOPICS:
=======

- Linux News

Slides
^^^^^^
- Linux Kernel Device
- Dateisysteme
- Flash Devices
- UBI
- Boot Prozess
- Dateisystem erzeugen
- UDEV


web
^^^
- Beagle Board Boot Configuration (Grafiken, Schaltplan)


Tafel
^^^^^
Komponentenliste erstellen (x-loader, u-boot, Kernel, RFS1, RFS2)
Was auf welches Medium / Partition


Board Bringup
^^^^^^^^^^^^^
- Komponenten erzeugen und Flashen



LWN - summary:
==============

13.04.2012:
^^^^^^^^^^^

More than eight years after the 2.6.0 release, Willy Tarreau has announced that
he will no longer be releasing updates to the 2.4 series.
For those who really are unable to move on, he may maintain a git tree with an
occasional fix, "but with no guarantees."

Development of SCHED_DEADLINE returns
 - it's a new scheduling policy like SCHED_FIFO
 - kernel git repo:     https://github.com/jlelli/sched-deadline
 - example application: https://github.com/gbagnoli/rt-app
 - Mailinglist:         http://feanor.sssup.it/mailman/listinfo/linux-dl

3.4-rc2 (released on April, 7th)
^^^^^^^

- The x32 system call ABI
		(https://sites.google.com/site/x32abi/documents/abi.pdf?attredirects=0&d=1)

- printk: support structured and multi-facility log messages
		(lwn.net/Articles/490690/)

- The Common Clk Framework (see drivers/clk/clk-*.c for examples)

- Introduce a led trigger for CPU activity and consolidate LED driver in ARM
		(lwn.net/Articles/489612/)

<< INSERT SLIDES ABOUT struct device >>

- Reworking the DMA mapping code Patchset
		* merge ARM DMA API in generic DMA code
		* remove duplicated code
		* remove special alloc/mapping functions for writecombine, (non)coherent
		* use flags in dma_(alloc/mapping) for writecombine, (non)coherent

		* now each architecture can implement the following functions:

include/linux/dma-mapping.h (very simplified pseudo code):

				struct dma_map_ops {
							vaddr = alloc(dev, size, &paddr, attr)
							free(dev, size, vaddr, paddr, attr)
							vaddr = mmap(dev, paddr, attr)
							sync_for_cpu (dev, paddr)
							sync_for_device (dev, vaddr)
							...
							yes/no = dma_supported(dev)
				};

				e.g. arm does this in arch/arm/common/dmabounce.c

		* add per-device i/o mmu support to (ARM) DMA API:

				Some hardware has a separate IOMMU built into it that cannot be used
				for other devices, so the IOMMU cannot be made available to the system
				as a whole.

				But it is possible to attach a device-specific dma_map_ops structure
				to such devices that would cause the DMA API to use the IOMMU without
				the device driver even needing to know about it.

arch/arm/include/asm/dma-iommu.h:

				struct dma_iommu_mapping {
							/* iommu specific data */
							struct iommu_domain     *domain;

							void                    *bitmap;
							size_t                  bits;
							unsigned int            order;
							dma_addr_t              base;

							spinlock_t              lock;
							struct kref             kref;
				};

				struct dma_iommu_mapping *arm_iommu_create_mapping(dma_addr_t base,
																						size_t size, int order);

				void arm_iommu_release_mapping(struct dma_iommu_mapping *mapping);

				int arm_iommu_attach_device(struct device *dev,
																						struct dma_iommu_mapping *mapping);
					(implementation see below)

arch/arm/mm/dma-mapping.c:

				struct dma_map_ops iommu_ops = {
							.alloc          = arm_iommu_alloc_attrs,
							.free           = arm_iommu_free_attrs,
							.mmap           = arm_iommu_mmap_attrs,

							.map_page               = arm_iommu_map_page,
							.unmap_page             = arm_iommu_unmap_page,
							.sync_single_for_cpu    = arm_iommu_sync_single_for_cpu,
							.sync_single_for_device = arm_iommu_sync_single_for_device,

							.map_sg                 = arm_iommu_map_sg,
							.unmap_sg               = arm_iommu_unmap_sg,
							.sync_sg_for_cpu        = arm_iommu_sync_sg_for_cpu,
							.sync_sg_for_device     = arm_iommu_sync_sg_for_device,
				};

				int arm_iommu_attach_device(struct device *dev,
																						struct dma_iommu_mapping *mapping)
				{
					int err;

					err = iommu_attach_device(mapping->domain, dev);
					if (err)
									return err;

					kref_get(&mapping->kref);
					dev->archdata.mapping = mapping;
					set_dma_ops(dev, &iommu_ops);

					printk(KERN_INFO "Attached IOMMU controller to %s device.\n",
						dev_name(dev));

					return 0;
				}


				Prior to this work, IOMMU awareness had been built into specific drivers
				directly.


Status of Android merge:
^^^^^^^^^^^^^^^^^^^^^^^^
Grant Likely asked about the progress of the Android patches into the mainline;
when is that job "done"?

Once Android is using mainline kernels was the answer Bottomley gave.

Kroah-Hartman noted that the real problem is on the user-space side.
Kernel hackers can't do anything about changing the Android user space,
but companies like Linaro and Samsung are making some progress in doing so.

The 3.3 kernel can boot an Android user space, but it will
"eat your battery alive",
he said. We are making progress, but it will require teamwork to get there.

Plumbers:
^^^^^^^^^

Udev and systemd to merge

Zawinski's Law.
Quick, someone write an email reader for systemd, to stop the progression before
it's too late. ;-)

Java and C swap places at the top of the TIOBE index (C: 17.555, Java 17.026 %)
(http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)


30.03.2012:
^^^^^^^^^^^

Long Term Kernel: 2.6.27.62, 2.6.32.59
Stable Kernel: 3.0.26, 3.1.10, 3.2.13

Mainline: 3.3 released on March 18th

 - byte queue limits
 - Open vSwitch
 - Network priority cgroup (Documentation/cgroups/net_prio.txt)
 - return of Android code into staging subtree
 - TI C6X arch support (DSP architecture - see https://lwn.net/Articles/457635/)
 - EFI boot support
 - Drivers

for a more complete list see (http://kernelnewbies.org/Linux_3.3)

Devel: 3.4 merge window is open

 - moved 'telephony' into staging
 - qnx6fs (readonly)
 - perf improvements
 - USB audio gadget
 - deferred driver probing
 - Remote Processor Framework (see Documentation/remoteproc.txt | rpmsg.txt)
 - more cleanup/consolidation on ARM

linux-next



Prüfung:
========
schriftlich, 60 Minuten

Material:
=========
http://manut.eu/hswgt

Script:
=======
Mitschriebe gerne an
manut@mecka.net

Literatur:
==========
http://lwn.net
http://heise.de/open <-- Kernel Log
http://kernelnewbies.org
http://beagleboard.org

Corbet, Rubini, Kroah-Hartmann: Linux Device Drivers 3rd Edition
  http://lwn.net/Kernel/LDD3

Kroah-Hartmann: Linux Kernel In A Nutshell
  http://www.kroah.com/lkn

Bovet, Cesati: Understanding The Linux Kernel (34,95)

Love: Linux Kernel Development (29,95 EUR)

Bewertung:
==========
http://www.meinprof.de/uni/prof/51131


geplante Themen:
================

Termin1:  what is linux:
------------------------
Voraussetzungen fuer Linux

Linux Desktop vs. embedded Linux:
 - Kernel vs. Userspace
 - Fedora, Debian, ubuntu ..
 - Android
 - KDE / GNOME
 - CPU Architekturen
 - cross

Kernelentwicklung
  - Mainline / Maintainer
  - syscalls (stabil)
  - interne API (instabil)
  Versionskontrolle:
    - diff / patch
    - quilt
    - git

Termin2: kernel build, bootloader, MTD:
---------------------------------------
Board Bringup:
 - Bootloader
 - grub vs. IPL vs. u-boot

Kernel:
 - Kernel konfigurieren
 - Kernel kompilieren (auch cross)
 - Kernel Dokumentation

Userspace:
 - RFS generieren
 - busybox / cross
 - read only RFS
 - 'kein' RFS vs. full-featured Debian

Praxis: Board Bringup

Termin3:
--------
Datenuebergabe zwischen Userspace und Kernel

Kernelarchitektur:
  - Core
  - Driver
  - Arch
  - Coding Style

Kernelmodule:
  - 1. Kernelmodul 'Hello world'
  registrieren bei Subsystemen:
  - char dev

Tracing


Termin4:
--------
Kernelkonzepte:
  Review eines Treibers:
    - IRQ Handling
    - MM
    - Timer
UIO:
  - UIO am Beispiel


Termin 5 & 6:
-------------
Kernelprogrammierung an einem Beispiel


Termin 7:
---------
Maintainer Vortrag & Questioning
Pruefungsvorbereitung


weitere Termine:
================
12.3 Vorlesungsbeginn
4.4 - 11.4 Ostern
18.5 Blutfreitag
25.5 - 04.6 Pfingsten

=> 12 Vorlesungsfreitage -> 14 taegig = 6 Veranstaltungen:

Vorschlag zur Terminplanung

30.3  - 1. Vorlesung

13.4  - 2. Vorlesung
20.4  - 3. Vorlesung
27.4

4.5   - 4. Vorlesung
11.5  - 5. Vorlesung

18.5  - Brueckentag (Christi Himmelfahrt)

8.6   - Brueckentag (Christi Himmelfahrt)
15.6  - 6. Vorlesung
22.6
29.6  - Vortrag von einem Kernelentwickler + Pruefungsvorbereitung (freiwillig)