From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Guthro Subject: Re: [PATCH 0/2][PV-on-HVM] Enable Front-end drivers for 2.4 kernels Date: Thu, 07 Feb 2008 09:53:02 -0500 Message-ID: <47AB1B4E.4010407@virtualiron.com> References: <47686EC3.30400@virtualiron.com> <476B36CF.30709@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: <476B36CF.30709@redhat.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: ddutile@redhat.com Cc: xen-devel List-Id: xen-devel@lists.xenproject.org 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_(). 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