config: untwist config backend prototypes

[metux]

• split the prototypes of individual backends into separate headers
• always define the functions (possibly empty) to cut down ifdef wood

Signed-off-by: Enrico Weigelt, metux IT consult [email protected]

[algrid]

I’m not sure about this. With the old code it was clear that only one config will be active. With this change I’m not sure what will happen if more than one of the “CONFIG_…” symbols are defined (could this happen in practice?).

[callmetango]

I’m not sure about this. With the old code it was clear that only one config will be active. With this change I’m not sure what will happen if more than one of the “CONFIG_…” symbols are defined (could this happen in practice?).

Same here and I am not sure why the #else branches were introduced. To my understanding this defines functions which maybe should not be defined and could turn compile time errors into runtime errors, no?

[metux]

Same here and I am not sure why the #else branches were introduced. To my understanding this defines functions which maybe should not be defined and could turn compile time errors into runtime errors, no?

See the removed #ifdef's at the call sites. The idea here is that callers don't need to explicitly care anymore - just the callees. It's a common practise, eg. also used in the Linux kernel, in order to move config dependencies out of the callees.