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