unmodified drivers question

unmodified drivers question

[Jan Beulich]

In platform-compat.h I find

#if defined(_LINUX_SYSRQ_H) && LINUX_VERSION_CODE > KERNEL_VERSION(2,6,18)
#define handle_sysrq(x,y,z) handle_sysrq(x,y)
#endif

which apparently assumes that non-ported Linux code (in this case
drivers/xen/core/reboot.c) is being compiled for newer kernel versions. If
that is the intended model (which I doubt is a generally workable one), a
second more natural model would need to be implemented by some means
so that building the drivers from an already forward ported tree is possible
(in the given case I'm talking about mentioned file already having the
handle_sysrq() converted to the two argument form).

Thanks for clarification,
Jan

Re: unmodified drivers question

[Keir Fraser]

The full extent of the model is to allow our 2.6.18 drivers to compile with
a range of vanilla kernel.org and related kernels. It's not a comprehensive
compat layer, but sufficient to build our drivers against most of the
kernels people seem to care about (mostly vendor kernels).

More precisely, drivers and other Xen-specific files are taken from our
2.6.18 tree, while all other headers and any other kernel metadata are
extracted from a native build tree. If you want to take the drivers and/or
Xen-specific files from a tree other than 2.6.18, you're on your own --
that's outside the scope of the unmodified_drivers/ directory's build system
(such as it is).

 -- Keir

On 23/10/07 07:33, "Jan Beulich" <jbeulich@novell.com> wrote:

> In platform-compat.h I find
> 
> #if defined(_LINUX_SYSRQ_H) && LINUX_VERSION_CODE > KERNEL_VERSION(2,6,18)
> #define handle_sysrq(x,y,z) handle_sysrq(x,y)
> #endif
> 
> which apparently assumes that non-ported Linux code (in this case
> drivers/xen/core/reboot.c) is being compiled for newer kernel versions. If
> that is the intended model (which I doubt is a generally workable one), a
> second more natural model would need to be implemented by some means
> so that building the drivers from an already forward ported tree is possible
> (in the given case I'm talking about mentioned file already having the
> handle_sysrq() converted to the two argument form).