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

[Ben Guthro <bguthro@xxxxxxxxxxxxxxx>]

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