Design system call interface for drivers

[zephyrbot]

Reported by Andrew Boie:

We need to design how we are going to do a system call interface for our device driver APIs. Currently our drivers use the device_get_binding() model which returns a device instance, and the APIs are all static functions that use API pointers. Show how we are going to do this with a system call scheme as unprivileged applications won't be able to do peripheral I/O directly.

(Imported from Jira ZEP-2183)

[zephyrbot]

by Andrew Boie:

I want to do this at the subsystem level, I want to touch the drivers as little as possible.
So right now pretty much all of our subsystems are implemented as a set of inline functions that then look inside the API struct pointed to by the device struct, and call the driver functions from there.
In a thread protection scenario, these subsystem APIs will:

1. Do the privilege elevation to supervisor mode
2. Validate the struct device pointers
3. Validate any user-supplied buffers, if any
4. Only then call into the driver implementation

Any given struct device would have a struct _k_object added to it. At boot we will iterate over all the driver instances (they are stored in the special initlevel section) and assign xor keys to them.

However, we need a different type of xor key for every driver type, we do not want users to be able to pass a driver object that implements, say, an ADC driver to the UART subsystem. We need some way of knowing what subsystem a particular struct device belongs to, AFAICT this is not currently possible.

The simplest way to do this is add a parameter to DEVICE_AND_API_INIT / DEVICE_DEFINE / DEVICE_INIT to take an enumerated type indicating what subsystem. This would just get put in the struct device and used to generate the correct XOR key. But this would be a hard API change, our policy is to deprecate public APIs for two releases and not just change them. Considering alternatives.

Other than adding this parameter to driver registration so that at runtime we can figure out what subsystem a driver instance belongs to, I don't anticipate any other changes to drivers.

[zephyrbot]

by Andrew Boie:

List of subsystems that use our driver / API struct model:

ADC
shared IRQ
Counter
Sensor
Watchdog
DMA
SPI
SPI legacy
RTC
flash
eth
random
i2c
pinmux
GPIO
crypto cipher
PWM
UART
AIO Comparator
Clock control
IPM