Hey, Sorry for the late reply. I really like the idea. Thank you for doing this Chris. A much needed feature. A possible use case just came to my mind.
One module might have to be shutdown before shutting down others for example: Sensors using I2C/SPI would have to be shut down before shutting down the underlying interfaces. This is kind of similar to pkg.init levels. I wanted to understand if you had any kind of priority in mind. Regards, Vipul Rahane > On Oct 1, 2018, at 10:44 AM, Andrzej Kaczmarek > <andrzej.kaczma...@codecoup.pl> wrote: > > Hi Chris, > > On Mon, Oct 1, 2018 at 7:39 PM Christopher Collins <ch...@runtime.io> wrote: > >> Hi Andrzej, >> >> On Sun, Sep 30, 2018 at 08:27:19PM +0200, Andrzej Kaczmarek wrote: >>> I guess device can be powered off simply as a power saving option or >>> shipping mode so perhaps 'reason' parameter could be added to shutdown >>> call. I do not know if it really matters to any package whether we >> shutdown >>> to reset device or just to power it off, but single extra parameter won't >>> hurt. >> >> Good idea. >> >>> Return codes feel like a bit more intuitive way to do this. You don't >>> really need to use branching in shutdown code, I think of two other ways >> to >>> do this: >>> 1. create array of pointers to functions and then main shutdown code can >>> call each function and examine return codes (or, a bit more complicated >>> way, create new section where these pointers are places and shutdown code >>> can also iterate them as array) >> >> Another good idea. I will try it out and report back! >> >>> 2. just return logical "or" of all return codes from all shutdown >> functions >>> - zero means shutdown is complete, non-zero means it's in progress (you >> can >>> make it a bitmask in case there's need to distinguish few status codes) >> >> I am having a hard time seeing how this would work. A logical-or of the >> return codes would only tell us if at least one subprocedure is still in >> progress. This is not enough information; we need to know exactly how >> many are still in progress so that we can determine when they have all >> completed (i.e., when the counter reaches 0). Are you envisioning a >> solution that does not require a counter? >> > > Ah, you're absolutely right. I forgot that we need to know how many > subprocedures are pending. So this option is not a solution here. > > Chris >> > > Best, > Andrzej
