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

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

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@virtualiron.com> 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


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

We tried to minimize the "ifdef mess" as much as possible to be 
encapulated in as few places as possible.
Which parts in particular concern you? If you could propose some 
suggestions - we could try another rev.

How would this patch lead to code divergence as submitted?

An ideal solution would be a 2.4.*-xen.hg tree which would support both 
PV, and PV-on-HVM solutions. However, that was not the goal of these 
patches.



Keir Fraser wrote:
> 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@virtualiron.com>
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
>>     
>
>
>   


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

I was thinking about solutions other than using ifdefs all over the place.
Given that the canonical drivers will soon be the upstream kernel.org
versions, we need a solution that doesn¹t rely on ifdefs in .c files (since
that seems to get rejected upstream). The Œdriver kit¹ I was thinking of
sounds rather like your own 2.4.*-xen.hg suggestion. Maybe that would be
best.

 -- Keir

On 19/12/07 12:26, "Ben Guthro" <bguthro@virtualiron.com> wrote:
> We tried to minimize the "ifdef mess" as much as possible to be
encapulated in
> as few places as possible.
> Which parts in particular concern you? If you could propose some
suggestions -
> we could try another rev.
> 
> How would this patch lead to code divergence as submitted?
> 
> An ideal solution would be a 2.4.*-xen.hg tree which would support both PV,
> and PV-on-HVM solutions. However, that was not the goal of these patches.



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

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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

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