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 structure.
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 ?
