Driver API implementation

Marcus Shawcroft <marcus.shawcroft@...>


While refactoring the device driver 'config_info' implementation(s)
such that config data can be const and romable I notice a similar
issue/opportunity w.r.t the driver API mechanism.

Currently we have:

struct device {
void *driver_api;

This pointer is used to reference a device class specific struct of
function pointers that collectively implement the upward facing API to
each driver instance. Every driver (almost) provides such a

This superficially looks to me like the kind of material we ought to
be pushing from RAM to ROM. Making *driver_api above const would
allow every driver to define its API structure as const.

Is this non const design deliberate, or an oversight? Does anyone have
objections to making the driver API machinery const, or see benefits
that out weigh the benefit of making these structures romable ?


Join to automatically receive all group messages.