>>> On Tue, Oct 3, 2006 at 6:31 PM, in message
>>> <4522E4AA.4020700@xxxxxxxxxxxxxxx>,
Steve Ofsthun <sofsthun@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home