Re: [Xen-devel] [PATCH 0/2][PV-on-HVM] Enable Front-end drivers for 2.4 kernels

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

That's a lot of ifdef mess for a feature that most people probably don't
want. I'm not sure what the right answer is for those who *do* want it. A
driver kit for Linux 2.4 would be neat, but could just lead to code
divergence.

 -- Keir


On 19/12/07 01:07, "Ben Guthro" <bguthro@xxxxxxxxxxxxxxx> wrote:

> This patch enables front end drivers to build under Linux 2.4. Specifically,
> the 2.4.21-47 kernel is used.  This corresponds to RedHat Linux 3 update 8
> release.
> 
> Changes were made in two areas.  Files were changed in the unmodified
> tree as
> well as the sparse tree.  The latter corresponds to the drivers/xen tree in
> the Linux 2.6.18 kernel and will be referred to as the "Linux driver
> tree" in
> the remainder of this note.
> 
> In the unmodified tree, changes were related to build system modifications,
> addition of missing header files, implementation of the generic device model
> code for kernel 2.4 and all other nuggets required to compile front end
> drivers
> under kernel 2.4.
> 
> In the Linux driver tree, changes made were located almost entirely in
> the front
> end drivers area.  Most of these were related to implementation of
> compatibility
> macros and replacement of APIs which evolved, were added or removed between
> kernels 2.4 and 2.6.  Where a one to one replacement of a specific call
> was not
> possible, blocks of code surrounded by kernel version specific preprocessor
> directives were added.  One instance of this is disk geometry processing.
> 
> Below is a more detailed list of changes made in the unmodified tree.
> 
> 1. Build system.  For each Kbuild file in the front driver area, a
>    corresponding K24build file has been created.  There, 2.4 style
> targets are
>    used.  The main Makefile for each driver references appropriate "K" file
>    depending on the kernel version the driver is being built for.
> 2. Nonexistent header files.  Header files included in front end drivers
> which
>    do not exist under kernel 2.4 were replaced by dummy headers.  These, in
>    turn, include compatibility headers to further resolve differences
> between
>    kernel 2.4 and 2.6.  Dummy header files reside in the
> compat-include/linux
>    tree.
> 3. Block interface.  Changed APIs are handled through compatibility
> macros whose
>    names are usually of the form compat_<original function name>().  This
>    applies to:
>    a. end request processing; Note that some of these macros take the same
>       number of arguments as original 2.6 APIs.  The change of name is
> necessary
>       because, while the corresponding 2.4 API exists, the number or type of
>       arguments might have changed.  This is the case for
>       end_that_request_first(), for example.  Additionally, as also
> happens to
>       be the case with this particular API, the way in which some APIs are
>       called varies between kernels 2.4 and 2.6.  Specifically, under kernel
>       2.6, end_that_request_first() is called once with a pointer to the
> request
>       being currently processed.  The rest is done by the kernel.  However,
>       under kernel 2.4, this API is called repeatedly until a certain return
>       code is obtained (which signals that the kernel is done with the
> current
>       request).  This difference of having to call it once (2.6) or,
>       potentially, many times (2.4) is covered in the corresponding
>       compatibility macro.
>    b. geometry calculations
>    c. references to bio and bio_vec structures are now translated into
>       references to buffer_head structures
>    d. resolution of driver's private data area pointer (struct blkfront_info
>       pointer)
>    e. resolution of the generic disk pointer
> 4. Work queue interface.  This is now implemented using scheduler task
> queue.
> 5. Kernel thread interface.  Those interfaces which are not defined
> under kernel
>    2.4 are implemented in the compatibility header file using 2.4
> versions of
>    thread functions.
> 6. Generic device model.  A simplified version of device model
> interfaces was
>    implemented to allow front end drivers to compile under kernel 2.4.  All
>    required structures appear in the compatibility header file.  All 2.4
>    versions of device model interfaces are implemented in
> platform-compat.c in
>    platform-pci.o driver.
> 
> This list details changes made in the Linux driver tree.
> 
> 1. Generic kernel compatibility header file.  Instead of including
>    xen/platform-compat.h which is compiled in only conditionally, a generic
>    compatibility header is included.  This file, named kerncompat.h is
> included
>    unconditionally and contains all compatibility macros used in front end
>    drivers.  Moreover, kerncompat.h conditionally includes platform-compat.h
>    just as it was done in the original front end driver code.  Unconditional
>    usage of kerncompat.h is necessary to give front end drivers access to
>    compatibility macros.
> 2. Disk driver initialization and setup.  Blocks of code needed to handle
>    generic disk operation were added and are compiled for kernels below
> 2.6.0.
> 3. Partition processing.  Blocks of code needed to process partition table
>    updates and geometry inquires were added.  These are conditionally
> compiled
>    for kernels below 2.6.0 only.
> 
> 
> Signed-off-by: Paul Burkacki <pburkacki@xxxxxxxxxxxxxxx>
> Signed-off-by: Ben Guthro <bguthro@xxxxxxxxxxxxxxx>
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel