[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: PV drivers for HVM guests

Gerd Hoffmann <kraxel@xxxxxxx> 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 ...
>   # 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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.