[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names
Paul Durrant writes ("RE: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names"): > Ok. I'll come up with something we can use to define an array and > then we can iterate over that. Great. What do people think of this preprocessor approach, which I suggested earlier: #define PVDRIVERS_LIST(EACH) \ EACH(WINDOWS, 0x0001 /* Citrix */, "xensource-windows") \ ... That can be used to generate arrays, or switch statements, or whatever. For example in pvdrivers.h: #define PVDRIVERS_EACH_ENUM(name,num,string) \ PVDRIVERS_ID_##name = num, enum { PVDRIVERS_LIST(PVDRIVERS_EACH_ENUM) }; and then in qemu: #define PVDRIVERS_EACH_SWITCH(name,num,string) \ case PVDRIVERS_ID_##name: product = string; break; switch (id) { PVDRIVERS_LIST(PVDRIVERS_EACH_SWITCH) default: sprintf blah blah } If the indirect macro trick is too abstruse it's also possible to do this: #define PVDRIVERS_LIST \ PVDRIVERS_EACH(WINDOWS, 0x0001 /* Citrix */, "xensource-windows") \ ... That can be used to generate arrays, or switch statements, or whatever. For example in pvdrivers.h: #define PVDRIVERS_EACH(name,num,string) \ PVDRIVERS_ID_##name = num, enum { PVDRIVERS_LIST }; #undef PVDRIVERS_EACH and then in qemu: #define PVDRIVERS_EACH(name,num,string) \ case PVDRIVERS_ID_##name: product = string; break; switch (id) { PVDRIVERS_LIST default: sprintf blah blah } #undef PVDRIVERS_EACH A #define containing an array initialiser is the other obvious alternative although of course the macro-based approaches I sketch above can be used to define arrays but not vice versa. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |