And that reminds me, that most of our drivers do not set driver API to
NULL if they fail. But they do return an explicit code which no one care about: see _sys_device_do_config_level() in kernel/nanokernel/device.c
I think there you can add also a tiny test:
if (device->init(info) < 0) { info->driver_api = NULL; }
Good point Tomasz. Might need to be part of the RFC patch that Daniel posted.
The original discussion was actually started about getting rid of returns of initialization functions.
Ok I missed that discussion.
The idea was that the kernel could not really do anything when a driver failed initialization, so why not getting rid of returns to save a few bytes. The burden of determining whether it is a critical error during init is up to the driver. If there is a critical error, the driver should assert (and setting driver_api to NULL).
There are situations where there are non-critical erros during initialization. For example, the I2C driver, failure to set default configuration is not critical. As long as the developer sets it later, the driver can still function. However, with the above code, this non-critical error will cause driver_api to be NULL, which prevents its usage at all. The driver writer should know whether an error prevents the device from functioning at all. So it should be up to driver writer to set driver_api to NULL. One can argue that a non-critical error should not return anything other than 0. But then it is not passing on the information that there is a non-critical error (though the kernel does not really care).
Your RFC patch was not clear about that. It would require to change the init function signature and all the existing drivers in one go as well. I hope we don't consider Kernel device API (init and stuff) as part of "API 1.0".
