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

[Ben Guthro <bguthro@xxxxxxxxxxxxxxx>]

Hi Don,

I thought I'd see if these patches might be available - or if they are 
still in development?
-Ben

Don Dutile wrote:
> 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@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