From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Dutile Subject: Re: [PATCH 0/2][PV-on-HVM] Enable Front-end drivers for 2.4 kernels Date: Thu, 20 Dec 2007 22:45:19 -0500 Message-ID: <476B36CF.30709@redhat.com> References: <47686EC3.30400@virtualiron.com> Reply-To: ddutile@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <47686EC3.30400@virtualiron.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ben Guthro Cc: Paul Burkacki , xen-devel List-Id: xen-devel@lists.xenproject.org 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_(). 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 > Signed-off-by: Ben Guthro > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel