Proposal: Ability to run initialization/teardown code for driver families

Several frameworks are used to implement multiple kinds of drivers. For example:

• SDL is used to implement video, audio, input, and controller drivers
• ALSA is used to implement audio and MIDI drivers
• Linuxraw and udev are used to implement input and controller drivers

These multi-purpose frameworks may have their own global state or configuration, such as SDL_LogSetOutputFunction or snd_lib_error_set_handler.

So let's say I want ALSA to log its errors via RARCH_ERR. I could set that up in alsa_init and clean it up in alsa_free. But here's the problem: What if I wanted to log errors in the alsa_midi driver? Who should set the log handler, and who should clean it up? What if somebody else outside of RetroArch configured snd_lib_error_set_handler (say, though a LD_PRELOAD)? Now there's an implicit dependency on the order in which drivers are set up and tear down.

Here's my proposed solution: Each driver with the same name shall be implicitly grouped into a "family". For example, the SDL drivers for video, audio, input, and controllers are all part of the sdl2 family. Here's how this works:

• For each driver family that's to be initialized, a single family-specific init function will be called before its constituent drivers are initialized. This can be used to initialize framework-specific global state such as error-handling or loggers. For instance, a hypothetical sdl_driver_family_init would be called if any of the SDL-based drivers are to be used.
• When a driver family is uninitialized, a single family-specific free function will be called, for the purpose of undoing whatever state was changed in init. This would be called after the constituent drivers are freed.
• Individual drivers would still be expected to maintain their own driver-specific state. So sdl_audio_init would still be responsible for calling SDL_Init(SDL_INIT_AUDIO).
• Driver families of size 1 are allowed, but pointless; all global state involving this driver could just be managed within the driver itself.
• There's no need to change how drivers are initialized or identified; it's enough to implicitly group drivers with the same name into families.

Start by tracing alsa_init and alsa_free in audio/drivers/alsa.c, then compare the SDL driver entry points linked in the issue. Confirm how drivers are identified and initialized before designing family-level hooks. Done means a family init runs once before its drivers and family cleanup runs after them, including shared SDL or ALSA state.