I've been reviewing a bunch of older esp32 pull requests and am a little puzzled. A bunch fall into the category of essentially exposing ESP-IDF functionality. For example, I2S #4471, smartconfig #4404, machine.Counter #5496, adjtime #5453, sigma-delta #5452, probably CAN #5310. I assume other ports have the same situation, e.g. with the STM32 HAL.

I'm wondering whether there is a way to enable these types of drivers without having to pull them into the MP core given that the PRs are not exactly moving very fast and are often difficult to review and to reach agreement upon. With the new ability to put C code into loadable MPY modules the main thing that seems to be missing is the ability to link.

I'm wondering whether an initial approach where PRs that only add functions to the mp_fun_table are readily accepted such that the drivers can be implemented in external repos could work. (The new functions could go into a specially marked section such that they could be replaced by a more sophisticated mechanism later.) Thoughts?

Pros:

• reduces PR bottleneck
• allows multiple driver models to co-exist, e.g. evolution of more sophisticated APIs
• allows machine-dependent drivers without "polluting" MP core repo

Cons:

• makes it harder to locate code, e.g. libraries and drivers scattered all around github
• may make higher-level libraries incompatible, e.g., lib A uses driver A while lib B uses driver B for the same peripheral
• reduces ability to create portable drivers by scattering code
• does it make debugging the native code harder?

See also #5463 (preliminary PR for docs on how to add functions to table)