[riot-notifications] [RIOT-OS/RIOT] RFC: Change of sensor and actoator API & auto initialization (#11826)

Marian Buschsieweke notifications at github.com
Fri Jul 12 16:56:23 CEST 2019

> I believe we should find a way to have *less* things in auto_init instead of *more*.

People tend to expect that an OS initializes its drivers. And I think for very fine reasons:

1. It reduces the boiler plate code in applications
2. The initialization code is well tested and easier to maintain, than having the same functionality and code duplicated for each and every user of the driver
3. It is simpler to use and simpler to use **correctly**
    a) It prevents applications from using the driver uninitialized
    b) It prevents two threads accessing a device from double-initialize a driver
    c) Even if the two threads would try to prevent double-initializing by checking if the driver is already initialized, this is inherently complex. E.g. the average application developer will likely write racy code that works by pure luck 99.9% of the time, with 0.1% ending up in two threads concurrently initializing the driver

> So not only does it cross module boundaries, it crosses the sys-drivers boundary.

This could be solved by moving driver initialization code to `drivers` (e.g. `drivers/auto_init`). But a boot sequence will always cross module-boundries. E.g. the startup code lives in `cpu`, which will e.g. call `board_init()` in `boards` and `periph_init` in `drivers`, and `kernel_init()` in `core`.

That said, I have nothing against moving driver initialization into `drivers`. But I'm strongly in favor of automatic initialization of the drivers (regardless of SAUL being used). (And of automatic registration of sensors and actuators to SAUL, if SAUL is used.)

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...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190712/dd380ce2/attachment.html>

More information about the notifications mailing list