I am trying to build PV drivers for SLES9 HVM guests. SLES 9 is based on the 2.6.5 kernel. Since the PV driver code is really designed for the latest kernel release, I have had many issues/problems in building the PV drivers for older Linux OS targets - I have only been looking at the issues with 2.6.5 kernel base and I suspect the problem will be even worse if one were to look at older Linux kernels. This is unfortunate since PV drivers are so critical for HVM guests and there is considerable interest in supporting legacy Linux environments as HVM guests. The problems I have had to deal with can be broadly classified into: a) Compiler related issues b) Missing functionality in the legacy kernel - this includes features as well as changed data structures c) Implementation differences of a given feature These differences can be dealt with in a couple of different ways: 1) Modify the code in the PV drivers under appropriate compilation switches to deal with the differences in the base kernels. 2) Introduce a compatibility component that bridges the gap between the current PV code and a given Linux target and leave much of the PV driver code untouched. I have implemented both these schemes for the sles9 kernel and would like to get your input on your preference. I personally like option 2. Going forward, the evolution of PV drivers needs to be constrained by the required support for legacy Linux environments. Regards, K. Y. Srinivasan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Interesting! Ideally, there would be better performance in the base HVM device model. I think I know of some people that are working hard on that. I''m curious to see what you''ve done for (1) and (2). Peace. Andrew On Tue, 2006-10-03 at 16:31 -0400, Ky Srinivasan wrote:> I am trying to build PV drivers for SLES9 HVM guests. SLES 9 is based on the 2.6.5 kernel. Since the PV driver code is really designed for the latest kernel release, I have had many issues/problems in building the PV drivers for older Linux OS targets - I have only been looking at the issues with 2.6.5 kernel base and I suspect the problem will be even worse if one were to look at older Linux kernels. This is unfortunate since PV drivers are so critical for HVM guests and there is considerable interest in supporting legacy Linux environments as HVM guests. The problems I have had to deal with can be broadly classified into: > > a) Compiler related issues > b) Missing functionality in the legacy kernel - this includes features as well as changed data structures > c) Implementation differences of a given feature > > These differences can be dealt with in a couple of different ways: > 1) Modify the code in the PV drivers under appropriate compilation switches to deal with the differences in the base kernels. > 2) Introduce a compatibility component that bridges the gap between the current PV code and a given Linux target and leave much of the PV driver code untouched. > > I have implemented both these schemes for the sles9 kernel and would like to get your input on your preference. I personally like option 2. Going forward, the evolution of PV drivers needs to be constrained by the required support for legacy Linux environments. > > Regards, > > K. Y. Srinivasan > > > > > > _______________________________________________ > 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
Ky Srinivasan wrote:> I am trying to build PV drivers for SLES9 HVM guests. SLES 9 is based on the 2.6.5 kernel. Since the PV driver code is really designed for the latest kernel release, I have had many issues/problems in building the PV drivers for older Linux OS targets - I have only been looking at the issues with 2.6.5 kernel base and I suspect the problem will be even worse if one were to look at older Linux kernels. This is unfortunate since PV drivers are so critical for HVM guests and there is considerable interest in supporting legacy Linux environments as HVM guests. The problems I have had to deal with can be broadly classified into: > > a) Compiler related issues > b) Missing functionality in the legacy kernel - this includes features as well as changed data structures > c) Implementation differences of a given feature > > These differences can be dealt with in a couple of different ways: > 1) Modify the code in the PV drivers under appropriate compilation switches to deal with the differences in the base kernels. > 2) Introduce a compatibility component that bridges the gap between the current PV code and a given Linux target and leave much of the PV driver code untouched. > > I have implemented both these schemes for the sles9 kernel and would like to get your input on your preference. I personally like option 2. Going forward, the evolution of PV drivers needs to be constrained by the required support for legacy Linux environments.We have generally taken approach 1, for supporting SLES9 32/64 & RHEL4 32/64, with others under development. While the code is uglier, it is also more obvious to a maintainer when they run across something like the following: #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,10) elevator_init(rq, "noop"); #else elevator_init(rq, &elevator_noop); #endif or #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,15) end_that_request_last( req, (bret->status == BLKIF_RSP_OKAY)); #else end_that_request_last(req); #endif In this way, the sensitive areas of the code are obvious. As the PV drivers move forward, new kernel interface changes require similar changes. As you mention, which ever method is used, some level of discipline is required in maintaining the PV drivers. With your suggested option 2, does this require separate "compatibility component" code for each supported kernel version? Or do you envision a single compatibility layer that would hide the conditionally compiled code from the PV drivers proper? There is also the issue of whether the PV drivers can/should support multiple hypervisor versions moving forward. Steve -- Steve Ofsthun - Virtual Iron Software, Inc. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 3/10/06 9:31 pm, "Ky Srinivasan" <ksrinivasan@novell.com> wrote:> These differences can be dealt with in a couple of different ways: > 1) Modify the code in the PV drivers under appropriate compilation switches to > deal with the differences in the base kernels. > 2) Introduce a compatibility component that bridges the gap between the > current PV code and a given Linux target and leave much of the PV driver code > untouched. > > I have implemented both these schemes for the sles9 kernel and would like to > get your input on your preference. I personally like option 2. Going forward, > the evolution of PV drivers needs to be constrained by the required support > for legacy Linux environments.A shim layer (i.e., a set of compat macros) that avoids ifdef''ing the core driver code is definitely the way to go. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, Oct 04, 2006 at 08:56:45AM +0100, Keir Fraser wrote:> > I have implemented both these schemes for the sles9 kernel and > > would like to get your input on your preference. I personally like > > option 2. Going forward, the evolution of PV drivers needs to be > > constrained by the required support for legacy Linux environments. > > A shim layer (i.e., a set of compat macros) that avoids ifdef''ing > the core driver code is definitely the way to go.FWIW, neither option has a chance of being accepted upstream. For upstream acceptance (assuming that it is a goal - it should be, otherwise you forever chase the latest kernel API change, multiplied by the number of different distro kernel trees you support) just write the latest version of the driver to the latest kernel version. But I suspect you already know this :-) Cheers, Muli _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 4/10/06 9:15 am, "Muli Ben-Yehuda" <muli@il.ibm.com> wrote:>> A shim layer (i.e., a set of compat macros) that avoids ifdef''ing >> the core driver code is definitely the way to go. > > FWIW, neither option has a chance of being accepted upstream. For > upstream acceptance (assuming that it is a goal - it should be, > otherwise you forever chase the latest kernel API change, multiplied > by the number of different distro kernel trees you support) just write > the latest version of the driver to the latest kernel version. But I > suspect you already know this :-)The versions in the upstream patches get cleaned up as necessary for acceptance. Yes, our aim is to get all the code support needed for PV-on-HVM drivers out of the external unmodified_drivers directory and properly into the Linux tree so that they can be built in-tree either for a PV kernel or a native kernel. Then the unmodified_drivers directory will contain only some build-system magic to make it easier to build drivers out-of-tree. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> These differences can be dealt with in a couple of different ways: > 1) Modify the code in the PV drivers under appropriate compilation > switches to deal with the differences in the base kernels. > 2) Introduce a compatibility component that bridges the gap between > the current PV code and a given Linux target and leave much of the > PV driver code untouched.How much code is actually required in this abstraction layer? Steven. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Muli Ben-Yehuda wrote:>> A shim layer (i.e., a set of compat macros) that avoids ifdef''ing >> the core driver code is definitely the way to go. > > FWIW, neither option has a chance of being accepted upstream.Exactly thats why a shim layer is the way to go (if possible, doesn''t work for all changes but for most). Did that that quite some time while maintaining the v4l subsystem. Making driver source code use the 2.6.latest conventions and have some compat.h header file full of stuff like this ... #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,xx) # define foo gryyz #endif or (better if possible as it catches distro backports, which does happen now and then for compiling recent drivers on old distro kernels). #ifndef bar # define bar xyzzy #endif nicely separates out the compat bits. It makes the code more readable and also is less work when submitting code upstream. cheers, Gerd -- Gerd Hoffmann <kraxel@suse.de> http://www.suse.de/~kraxel/julika-dora.jpeg _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Gerd Hoffmann <kraxel@suse.de> writes:> Muli Ben-Yehuda wrote: > >> A shim layer (i.e., a set of compat macros) that avoids ifdef''ing > >> the core driver code is definitely the way to go. > > > > FWIW, neither option has a chance of being accepted upstream. > > Exactly thats why a shim layer is the way to go (if possible, doesn''t > work for all changes but for most). Did that that quite some time while > maintaining the v4l subsystem. Making driver source code use the > 2.6.latest conventions and have some compat.h header file full of stuff > like this ... > > #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,xx) > # define foo gryyz > #endif > > or (better if possible as it catches distro backports, which does happen > now and then for compiling recent drivers on old distro kernels). > > #ifndef bar > # define bar xyzzy > #endif > > nicely separates out the compat bits. It makes the code more readable > and also is less work when submitting code upstream.I hate to point out the obvious, but often when calls get renamed upstream it is actually because the semantics changed subtly (the point of the rename was to enforce a audit and proper fix of the driver) Typically then using define bar xyz is then not the right thing to do. Especially when you do #define oldfunctionname newfunctionname without any translation you very likely have a bug. A shim layer can be the right thing to do still, but you have to be very careful to not miss such a semantics change. -Andi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> On Tue, Oct 3, 2006 at 6:31 PM, in message <4522E4AA.4020700@virtualiron.com>,Steve Ofsthun <sofsthun@virtualiron.com> wrote:> Ky Srinivasan wrote: >> I am trying to build PV drivers for SLES9 HVM guests. SLES 9 is based on the > 2.6.5 kernel. Since the PV driver code is really designed for the latest > kernel release, I have had many issues/problems in building the PV drivers > for older Linux OS targets - I have only been looking at the issues with 2.6.5 > kernel base and I suspect the problem will be even worse if one were to look > at older Linux kernels. This is unfortunate since PV drivers are so critical > for HVM guests and there is considerable interest in supporting legacy Linux > environments as HVM guests. The problems I have had to deal with can be > broadly classified into: >> >> a) Compiler related issues >> b) Missing functionality in the legacy kernel - this includes features as > well as changed data structures >> c) Implementation differences of a given feature >> >> These differences can be dealt with in a couple of different ways: >> 1) Modify the code in the PV drivers under appropriate compilation switches > to deal with the differences in the base kernels. >> 2) Introduce a compatibility component that bridges the gap between the > current PV code and a given Linux target and leave much of the PV driver > code untouched. >> >> I have implemented both these schemes for the sles9 kernel and would like to > get your input on your preference. I personally like option 2. Going forward, > the evolution of PV drivers needs to be constrained by the required support > for legacy Linux environments. > > We have generally taken approach 1, for supporting SLES9 32/64 & RHEL4 32/64, > with others > under development. While the code is uglier, it is also more obvious to a > maintainer when > they run across something like the following: > > #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,10) > elevator_init(rq, "noop"); > #else > elevator_init(rq, &elevator_noop); > #endif > > or > > #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,15) > end_that_request_last( > req, (bret- >status == BLKIF_RSP_OKAY)); > #else > end_that_request_last(req); > #endif > > In this way, the sensitive areas of the code are obvious. As the PV drivers > move forward, > new kernel interface changes require similar changes. As you mention, which > ever method > is used, some level of discipline is required in maintaining the PV drivers. > > With your suggested option 2, does this require separate "compatibility > component" code > for each supported kernel version? Or do you envision a single > compatibility layer that > would hide the conditionally compiled code from the PV drivers proper?Based on the nature and extent of the changes we may either go with one compatibility component for all legacy kernel targets or one for each.> > There is also the issue of whether the PV drivers can/should support > multiple hypervisor > versions moving forward.Good point.> > Steve_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Andrew, The I/O performance of HVM guests with PV drivers is SIGNIFICANTLY better than what we get without PV drivers. I will post the patches after some additional testing and code cleanup. Regards, K. Y>>> On Tue, Oct 3, 2006 at 6:19 PM, in message<1159913996.27206.37.camel@localhost>, "Andrew D. Ball" <aball@us.ibm.com> wrote:> Interesting! Ideally, there would be better performance in the base HVM > device model. I think I know of some people that are working hard on > that. > > I''m curious to see what you''ve done for (1) and (2). > > Peace. > Andrew > > On Tue, 2006- 10- 03 at 16:31 - 0400, Ky Srinivasan wrote: >> I am trying to build PV drivers for SLES9 HVM guests. SLES 9 is based on the > 2.6.5 kernel. Since the PV driver code is really designed for the latest > kernel release, I have had many issues/problems in building the PV drivers > for older Linux OS targets - I have only been looking at the issues with 2.6.5 > kernel base and I suspect the problem will be even worse if one were to look > at older Linux kernels. This is unfortunate since PV drivers are so critical > for HVM guests and there is considerable interest in supporting legacy Linux > environments as HVM guests. The problems I have had to deal with can be > broadly classified into: >> >> a) Compiler related issues >> b) Missing functionality in the legacy kernel - this includes features as > well as changed data structures >> c) Implementation differences of a given feature >> >> These differences can be dealt with in a couple of different ways: >> 1) Modify the code in the PV drivers under appropriate compilation switches > to deal with the differences in the base kernels. >> 2) Introduce a compatibility component that bridges the gap between the > current PV code and a given Linux target and leave much of the PV driver > code untouched. >> >> I have implemented both these schemes for the sles9 kernel and would like to > get your input on your preference. I personally like option 2. Going forward, > the evolution of PV drivers needs to be constrained by the required support > for legacy Linux environments. >> >> Regards, >> >> K. Y. Srinivasan >> >> >> >> >> >> _______________________________________________ >> 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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> On Wed, Oct 4, 2006 at 3:56 AM, in message<C14927CD.2084%Keir.Fraser@cl.cam.ac.uk>, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:> On 3/10/06 9:31 pm, "Ky Srinivasan" <ksrinivasan@novell.com> wrote: > >> These differences can be dealt with in a couple of different ways: >> 1) Modify the code in the PV drivers under appropriate compilation switches > to >> deal with the differences in the base kernels. >> 2) Introduce a compatibility component that bridges the gap between the >> current PV code and a given Linux target and leave much of the PV driver > code >> untouched. >> >> I have implemented both these schemes for the sles9 kernel and would like to >> get your input on your preference. I personally like option 2. Going > forward, >> the evolution of PV drivers needs to be constrained by the required support >> for legacy Linux environments. > > A shim layer (i.e., a set of compat macros) that avoids ifdef''ing the core > driver code is definitely the way to go. > > -- KeirThanks Kier; this is also my preference. To keep the shim layer small, we may still have some ifdefs in the driver code though(to deal with non-existent header files that are included etc). Regards, K. Y _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> On Wed, Oct 4, 2006 at 4:15 AM, in message<20061004081551.GC6274@rhun.haifa.ibm.com>, Muli Ben-Yehuda <muli@il.ibm.com> wrote:> On Wed, Oct 04, 2006 at 08:56:45AM +0100, Keir Fraser wrote: > >> > I have implemented both these schemes for the sles9 kernel and >> > would like to get your input on your preference. I personally like >> > option 2. Going forward, the evolution of PV drivers needs to be >> > constrained by the required support for legacy Linux environments. >> >> A shim layer (i.e., a set of compat macros) that avoids ifdef''ing >> the core driver code is definitely the way to go. > > FWIW, neither option has a chance of being accepted upstream. For > upstream acceptance (assuming that it is a goal - it should be, > otherwise you forever chase the latest kernel API change, multiplied > by the number of different distro kernel trees you support) just write > the latest version of the driver to the latest kernel version. But I > suspect you already know this :- )Agreed. Having a clean shim should help in getting the PV driver code upstream. Regards, K. Y _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> Steven Smith <sos22-xen@srcf.ucam.org> 10/04/06 6:24 AM >>> >> These differences can be dealt with in a couple of different ways: >> 1) Modify the code in the PV drivers under appropriate compilation >> switches to deal with the differences in the base kernels. >> 2) Introduce a compatibility component that bridges the gap between >> the current PV code and a given Linux target and leave much of the >> PV driver code untouched. >How much code is actually required in this abstraction layer?Not a whole lot. The shim layer I currently have is about 80 lines (about 40 lines in a header file and about 40 lines in a c file). Along with this I have a few ifdefs in the PV driver code to deal with non-existent header files and non-existent fields in data structures such as struct bus_type, struct device etc. Regards, K. Y _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Agreed. What I meant is that it would be nice if the device model were modified to have better performance for things like OS/2, where writing paravirtual drivers would be less emphasized. Peace. Andrew Ky Srinivasan wrote:> Andrew, > > The I/O performance of HVM guests with PV drivers is SIGNIFICANTLY better than what we get without PV drivers. I will post the patches after some additional testing and code cleanup. > > Regards, > > K. Y > > >>>>On Tue, Oct 3, 2006 at 6:19 PM, in message > > <1159913996.27206.37.camel@localhost>, "Andrew D. Ball" <aball@us.ibm.com> > wrote: > >>Interesting! Ideally, there would be better performance in the base HVM >>device model. I think I know of some people that are working hard on >>that. >> >>I''m curious to see what you''ve done for (1) and (2). >> >>Peace. >>Andrew >> >>On Tue, 2006- 10- 03 at 16:31 - 0400, Ky Srinivasan wrote: >> >>>I am trying to build PV drivers for SLES9 HVM guests. SLES 9 is based on the >> >>2.6.5 kernel. Since the PV driver code is really designed for the latest >>kernel release, I have had many issues/problems in building the PV drivers >>for older Linux OS targets - I have only been looking at the issues with 2.6.5 >>kernel base and I suspect the problem will be even worse if one were to look >>at older Linux kernels. This is unfortunate since PV drivers are so critical >>for HVM guests and there is considerable interest in supporting legacy Linux >>environments as HVM guests. The problems I have had to deal with can be >>broadly classified into: >> >>>a) Compiler related issues >>>b) Missing functionality in the legacy kernel - this includes features as >> >>well as changed data structures >> >>>c) Implementation differences of a given feature >>> >>>These differences can be dealt with in a couple of different ways: >>>1) Modify the code in the PV drivers under appropriate compilation switches >> >>to deal with the differences in the base kernels. >> >>>2) Introduce a compatibility component that bridges the gap between the >> >>current PV code and a given Linux target and leave much of the PV driver >>code untouched. >> >>>I have implemented both these schemes for the sles9 kernel and would like to >> >>get your input on your preference. I personally like option 2. Going forward, >>the evolution of PV drivers needs to be constrained by the required support >>for legacy Linux environments. >> >>>Regards, >>> >>>K. Y. Srinivasan >>> >>> >>> >>> >>> >>>_______________________________________________ >>>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 > > > > > _______________________________________________ > 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
Agreed. K. Y>>> On Thu, Oct 5, 2006 at 10:59 AM, in message <45251DEB.1070708@us.ibm.com>,"Andrew D. Ball" <aball@us.ibm.com> wrote:> Agreed. What I meant is that it would be nice if the device model > were modified to have better performance for things like OS/2, where > writing paravirtual drivers would be less emphasized. > > Peace. > Andrew > > Ky Srinivasan wrote: >> Andrew, >> >> The I/O performance of HVM guests with PV drivers is SIGNIFICANTLY better > than what we get without PV drivers. I will post the patches after some > additional testing and code cleanup. >> >> Regards, >> >> K. Y >> >> >>>>>On Tue, Oct 3, 2006 at 6:19 PM, in message >> >> <1159913996.27206.37.camel@localhost>, "Andrew D. Ball" <aball@us.ibm.com> >> wrote: >> >>>Interesting! Ideally, there would be better performance in the base HVM >>>device model. I think I know of some people that are working hard on >>>that. >>> >>>I''m curious to see what you''ve done for (1) and (2). >>> >>>Peace. >>>Andrew >>> >>>On Tue, 2006- 10- 03 at 16:31 - 0400, Ky Srinivasan wrote: >>> >>>>I am trying to build PV drivers for SLES9 HVM guests. SLES 9 is based on the >>> >>>2.6.5 kernel. Since the PV driver code is really designed for the latest >>>kernel release, I have had many issues/problems in building the PV drivers >>>for older Linux OS targets - I have only been looking at the issues with > 2.6.5 >>>kernel base and I suspect the problem will be even worse if one were to look >>>at older Linux kernels. This is unfortunate since PV drivers are so critical >>>for HVM guests and there is considerable interest in supporting legacy Linux >>>environments as HVM guests. The problems I have had to deal with can be >>>broadly classified into: >>> >>>>a) Compiler related issues >>>>b) Missing functionality in the legacy kernel - this includes features as >>> >>>well as changed data structures >>> >>>>c) Implementation differences of a given feature >>>> >>>>These differences can be dealt with in a couple of different ways: >>>>1) Modify the code in the PV drivers under appropriate compilation switches >>> >>>to deal with the differences in the base kernels. >>> >>>>2) Introduce a compatibility component that bridges the gap between the >>> >>>current PV code and a given Linux target and leave much of the PV driver >>>code untouched. >>> >>>>I have implemented both these schemes for the sles9 kernel and would like to >>> >>>get your input on your preference. I personally like option 2. Going forward, > >>>the evolution of PV drivers needs to be constrained by the required support >>>for legacy Linux environments. >>> >>>>Regards, >>>> >>>>K. Y. Srinivasan >>>> >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>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 >> >> >> >> >> _______________________________________________ >> 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
On Tue, 2006-10-03 at 16:31 -0400, Ky Srinivasan wrote:> 2) Introduce a compatibility component that bridges the gap between > the current PV code and a given Linux target and leave much of the PV > driver code untouched. > > I have implemented both these schemes for the sles9 kernelFWIW I have a half complete implementation (compile tested only) of such a scheme which I''ve attached, perhaps you can crib something useful from it ;-). Basically it adds a compat-include directory to the end of the include search path which contains compatibility versions of headers which may not present in older kernels and adds compat.h which defines other missing bits where necessary. It covers most of the issues compiling against a RHEL4 (2.6.9) or SLES9 (2.6.5) kernel, although compatibility shims for schedule_timeout_interruptible() and nonseekable_open() are still missing and the versions used for triggering compatibility code are certainly totally wrong (just right for RHEL4 and SLES9 though ;-)). I''m fairly unhappy about the number of ifdef''s in xenbus_probe.c. I reckon some function reordering could coalesce a lot of them. Perhaps they are candidates for splitting into a separate file. This work will also be useful for the fully PV vendor kernel ports which is why I''m interested. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Thanks Ian. I am currently testing my implementation on sles9. I will certainly look at how I can leverage your work. Regards, K. Y>>> On Thu, Oct 5, 2006 at 11:21 AM, in message<1160061687.3755.101.camel@localhost.localdomain>, Ian Campbell <Ian.Campbell@XenSource.com> wrote:> On Tue, 2006- 10- 03 at 16:31 - 0400, Ky Srinivasan wrote: >> 2) Introduce a compatibility component that bridges the gap between >> the current PV code and a given Linux target and leave much of the PV >> driver code untouched. >> >> I have implemented both these schemes for the sles9 kernel > > FWIW I have a half complete implementation (compile tested only) of such > a scheme which I''ve attached, perhaps you can crib something useful from > it ;- ). > > Basically it adds a compat- include directory to the end of the include > search path which contains compatibility versions of headers which may > not present in older kernels and adds compat.h which defines other > missing bits where necessary. > > It covers most of the issues compiling against a RHEL4 (2.6.9) or SLES9 > (2.6.5) kernel, although compatibility shims for > schedule_timeout_interruptible() and nonseekable_open() are still > missing and the versions used for triggering compatibility code are > certainly totally wrong (just right for RHEL4 and SLES9 though ;- )). > > I''m fairly unhappy about the number of ifdef''s in xenbus_probe.c. I > reckon some function reordering could coalesce a lot of them. Perhaps > they are candidates for splitting into a separate file. > > This work will also be useful for the fully PV vendor kernel ports which > is why I''m interested. > > Ian._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, Ian Campbell wrote:> On Tue, 2006-10-03 at 16:31 -0400, Ky Srinivasan wrote: >> 2) Introduce a compatibility component that bridges the gap between >> the current PV code and a given Linux target and leave much of the PV >> driver code untouched. >> >> I have implemented both these schemes for the sles9 kernel > > FWIW I have a half complete implementation (compile tested only) of such > a scheme which I''ve attached, perhaps you can crib something useful from > it ;-).I modified Ian''s patch for RHEL4. We''ve tested compiling and attaching them on RHEL4. In our simple test, PV-on-HVM VBD/VNIF drivers work on RHEL4 original kernel. Thanks, - Tsunehisa Doi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi all, DOI Tsunehisa wrote:> I modified Ian''s patch for RHEL4. > > We''ve tested compiling and attaching them on RHEL4. In our simple > test, PV-on-HVM VBD/VNIF drivers work on RHEL4 original kernel.I checked several version of kernel source, and modified the patch. This patch is modified from Ian''s patch: + move compat.c from xenbus to platform-pci - platform-pci needs vmalloc_to_pfn() realized in compat.c * platform-pci is inserted before xenbus insertion. + append schedule_timeout_interruptible() to compat.c - the code was copied from linux/kernel/timer.c + append do_exit() faker to compat.c - the faker was implemented using complete_and_exit() + delete vmalloc_to_page() from compat.c - vmalloc_to_page() already exists in linux-2.6.0 kernel. + conferm version for several features - do conferm version about "TODO: conferm version" We''ve tested compiling and attaching them on RHEL4. And they work on RHEL4 in same test. Thanks, - Doi Tsunehisa _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi all,
I found some issue with my old patch.
+ Fix do_exit() faker type
- can''t compile on linux-2.6.10 and 2.6.11
- do_exit() faker is mismatched with original header.
- do_exit type changed after linux-2.6.10
< asmlinkage NORET_TYPE void do_exit(long code);
> fastcall NORET_TYPE void do_exit(long code);
+ Fix compat-include/linun/mutex.h about version checker
- change reference version from 2.6.16 to 2.6.15
DOI Tsunehisa wrote:> Hi all,
>
> DOI Tsunehisa wrote:
>> I modified Ian''s patch for RHEL4.
>>
>> We''ve tested compiling and attaching them on RHEL4. In our
simple
>> test, PV-on-HVM VBD/VNIF drivers work on RHEL4 original kernel.
>
> I checked several version of kernel source, and modified the patch.
>
> This patch is modified from Ian''s patch:
>
> + move compat.c from xenbus to platform-pci
> - platform-pci needs vmalloc_to_pfn() realized in compat.c
> * platform-pci is inserted before xenbus insertion.
> + append schedule_timeout_interruptible() to compat.c
> - the code was copied from linux/kernel/timer.c
> + append do_exit() faker to compat.c
> - the faker was implemented using complete_and_exit()
> + delete vmalloc_to_page() from compat.c
> - vmalloc_to_page() already exists in linux-2.6.0 kernel.
> + conferm version for several features
> - do conferm version about "TODO: conferm version"
>
> We''ve tested compiling and attaching them on RHEL4. And they
> work on RHEL4 in same test.
>
> Thanks,
> - Doi Tsunehisa
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On Fri, 2006-10-13 at 11:00 +0900, DOI Tsunehisa wrote:> I found some issue with my old patch.Thanks for these. I''ll look at them properly once the 3.0.3 release is out and the unstable tree has opened again. Cheers, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel