Re: PV drivers for HVM guests

[Andi Kleen <ak@suse.de>]

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