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

[Don Dutile <ddutile@redhat.com>]

Our apologies for the late notice, but RedHat has a set of
patches that apply to a xen-3.1.0 tarball to yield a set
of functioning pv-on-hvm drivers for RHEL3-U8 (& U9).
[A reduced set of patches would yield the same result w/3.1.2 .]

Our plans are to provide those patches to xen-devel in January,
after further cleanup (so they don't break 2.6 builds).

The patches have some similarities & differences to those listed
below.  More specifically, they have what is described in 4, 5, & 6
(although I haven't had the time to compare the two implementations, but
a wheel typically comes out round ;-) ).
The patches differ in that h-file diffs are handled in the compat-include
directory.  Additionally, the block device support is handled by a new set of
interfaces, reducing potential issues of modifying this code for
Linux 2.4 breaking Linux 2.6, or vice versa.
The patches don't include a build system as described below, which
sounds like a clean way to handle those diffs, and avoid 2.4 vs 2.6 changes/diffs
over time (much like our separate block interface support split for 2.4
avoids conflicts/issues w/2.6).

The heavy lifting for this support was done by Herbert Xu.
I've been adding bug fixes and getting it into a clean set of 
patches that can create an rpm that can be added to a rhel3 kernel,
as well as working with a number of testers asking for this support on rhel3.

We'll look at the following patches in detail after the New Year.
(We turn into a pumpkin next week, and the fairy tale ends 1/2/08),
and see what we can meld into a patch set that takes the best
of both worlds.

- Don
===========================================================

Ben Guthro 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@virtualiron.com>
> Signed-off-by: Ben Guthro <bguthro@virtualiron.com>
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel