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

[Ben Guthro <bguthro@virtualiron.com>]

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@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