User Tools

Site Tools


driver-backport:exchange-format

Contents

Overview

In a general sense, the term “driver backport” can be used to describe any type of driver source structure which allows a driver coded for one kernel version to be built on another kernel version. This broad definition is flexible but does not contain enough structure or specificity to be useful in further standardization efforts. Therefore, this page defines/proposes a more stringent “Driver Backport Exchange Format” (DBEF) to be used in driver backports.

Scope

The driver backport exchange format specified here includes the information necessary to build an upstream driver for a specific distro/kernel. It does not include information (spec file, etc.) necessary to package the driver in a specific format.

Format Details

Directory Structure

A driver backport should contain the following directory structure and files:

   <driver-name>-backport
       <driver-name>-backport.conf
       source-<version_1>
           *.c
           *.h
           Kbuild/Makefile
           patches
               patch_x
               patch_y
               ...
       source-<version_2>
           *.c
           *.h
           Kbuild/Makefile
           patches
               patch_x
               patch_y
               ...
       ...

Using <driver-name>-backport for the top-level directory and <driver-name>-backport.conf are suggestions, not requirements.

Config file Specification

The <driver-name>-backport.conf file contains the following required and optional information:

   driver-location: <URL>
   <target_1>: <source> <list of patches>
   <target_2>: <source> <list of patches>
   ...
   [alias: <target> <target>]
   [ramFS]

The driver location is a URL to an official upstream source.

The targets are the kernel and/or distro versions that the backport supports. The target tag may be simply a kernel version (e.g., “2.6.5”), it may be a distribution (e.g., “sles10sp1”), or it may be some other user-defined string (e.g., “my-favorite-kernel”). After each target is 1) the source to start from, then 2) a list of patches to be applied to the source in order to create code that can be built on the target. The order of patches is significant: they are to be applied in the order listed.

The aliases provide a means to specify additional targets which use the same source as previously-listed targets. E.g., an alias might indicate that a new target “sles10sp2” uses the same source as the target “sles10sp1”, which requires a specific list of patches.

The “ramFS” line indicates that the driver should be included in the initial ram disk.

Examples

driver-backport/exchange-format.txt · Last modified: 2016/07/20 00:22 (external edit)