Re: RFC: return type of functions passed to DEVICE_INIT()

Thomas, Ramesh

On Thu, 2016-02-18 at 12:34 -0800, Dirk Brandewie wrote:

On 02/18/2016 10:03 AM, Benjamin Walsh wrote:

My take on it is that for Zephyr a failed device initialization
should be considered a fatal event. My expectation is that the
Zephyr user will only be enabling relevant (and important) devices to
their project. If one of these devices should fail, then that is a
serious system error and _NanoFatalErrorHandler() should be invoked.
How about a CONFIG option to determine if kernel should abort boot? The
behavior should be determined by the kind of application. Some can live
with less features while for others it is all or nothing. In both cases
a logging feature that can be queried by the app would be useful.

Any of those could be a valid approach I think, but we have to decide on
one. And right now, we have the worst since we return those error codes
which are meant for runtime handling, but they just go into the void.
+1 _sys_device_do_config_level() should at least pass on the error
returned even if one device fails. This as well as the
"resume_all/suspend_all" functions can be called by app in power
management case. It would be useful for the app to know that something
went wrong.

Question still remains whether _sys_device_do_config_level() should
continue with other devices if one fails. IMO it should continue but
should return error if one device had failed. At boot time, kernel can
save the error condition somewhere to be queried by the app.


If we want to let the application handle the initialization issues, we
probably need some kind of queue that gets filled by the init system
when init functions return errors, and that the application drains to
see what failed. We might want to queue the associated device objects,
and have an errno field in there, or something like that.
The app would be anyway getting a failure when it tries to use the
device. It most probably cannot rectify any device error on the fly with
more detailed info. Just my thought

A simple status from _sys_device_do_config_level() is probably enough so
the app can decide whether to continue or abort.

Join to automatically receive all group messages.