[riot-notifications] [RIOT-OS/RIOT] RFC: Change of sensor and actuator API & auto initialization (#11826)
notifications at github.com
Sun Jul 14 17:48:31 CEST 2019
> I don't really get why you gave this excursion, since it'd only support your point in case it was the standard for OSs to initialize drivers and thus everyone is used to this behaviour. I don't what to get all rhetoric, but even considering standards for OS driven sensor initialisation seems weird to me.
It is commonly considered beneficial to be aware of core design goals of a software project. It is commonly considered beneficial to know the reasons and historic context behind core design goals. And it is also commonly considered as a strong argument to point out that one design decision is aligned with a core design goal and another is not.
All POSIX compliant OS have their drivers initialized during boot up. (Try `cat /sys/class/thermal/thermal_zone<NUM>/temp` on a Linux machine. The temperature sensors are *always* initialized once the userspace API (the special file) is accessible.)
A core design goal of RIOT is that it *can* be used similar to a POSIX compliant OS. (This does not mean RIOT cannot also provide non-POSIX-like alternatives - e.g. RIOT's sock API can be used instead of the POSIX socket API.)
> Anyone interested in using auto_init for their sensors should not be interested in managing the sensor themselves.
I don't get this. Anyone wanting to *use* a driver has a *strong* interest in having it initialized. E.g. SAUL is not *manageing* the drivers, but *using* them. And SAUL *allows* the user to auto_initialize and register the drivers with `saul_auto_init` (which is a dependency of `saul_default`). The user can just as well not use `saul_auto_init` and do the initialization and registration himself/herself.
But you are forgetting one important point: If there is a module to auto initialize sensor / actuator drivers, the user can decide to use it or still initialize them manually. If there is no such module, the decision to manually initialize the driver is forced upon the user.
The saul auto init module is failing to provide users access to the driver (as the device descriptors are marked as `static`). E.g. when writing a test application for a sensor driver, you cannot expose both the internal API and the SAUL API of the driver at the same time (at least when using `saul_auto_init`, which is worth to test as well). The current architecture/API prevents me from providing a simple test application that covers the whole feature set of a sensor driver (that is: the native API, the SAUL API and the `saul_auto_init` hook). I consider this a bug that needs fixing.
> Even if this is a wanted feature it might as well be a part of the driver (e.g. status flags/mutex guarding function calls).
Quoting the [RIOT maintainer guideline](https://github.com/RIOT-OS/RIOT/blob/master/MAINTAINING.md#1---review-the-fundamentals):
> Is the solution presented in the PR as simple as possible to satisfy the requirements, but no simpler?
Adding to *every* function of the driver a check if the driver is already initialized and a conditional call to the init function increases complexity and code size, compared to providing an auto-initialize. Just ask yourself: From where should e.g. `foo_read_temperature(foo_t *dev, int16_t *temp)` take the `foo_params_t`?
> > So then lets fix these APIs ;-)
> You know yourself how hard this is
Designing good APIs is hard, let's go shopping?!?
> 1. Is auto-initialization of sensor and actuator drivers is desired?
> 2. Should using the native sensor/actuator API and SAUL no longer be mutually exclusive?
> 3. And, if the first two questions are answered with yes: How should the sensor/actuator APIs be changed to achieve this?
Being completely honest: I considered the questions 1. and 2. to be rhetorical. Every use case relying on manual initialization is not harmed by having a module that *can* auto-initialize drivers: That app will just not use e.g. `USEMODULE += auto_init_sensors` the same way as it was not using `USEMODULE += auto_init_saul` so far. And 90% of the users will be happy to have the drivers ready to use with the default parameters by simply adding the auto init module.
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the notifications