On 2/26/25 01:50, Linus Walleij wrote:
On Tue, Feb 25, 2025 at 7:25 PM Ayush Singh <ayushsingh1325@xxxxxxxxx> wrote:
One of the reasons of the prevalence of userspace drivers (and probably
the reason why kernel drivers for stuff like motors are not attractive)
is the lack of upstream solution for runtime devicetree overlays.
Given how long device tree overlays have been talked about
and hypothesized I am of the opinion that they are never
going to fly.
My main complaints being that they are just too complex and hard
on users: special tools needed, compile files, files relate to other
existing dts(i) files that you also need to have at your disposal etc.
Well, devicetree overlays also have some benefits. Particularly that it
is an open standard, and can be shared with ZephyrRTOS, if done properly.
The syntax itself is not particularly hard, and it isn't difficult to
create tools to make creating device trees easier.
The current compiler errors are not great to be honest, but that is
mostly due to the fact the barrier to entry for end users is quite
high (go u-boot route or modify the current device tree) instead of
sysfs APIs which other tools can interact with to generate overlays
on the fly. In short, if the kernel provides a userspace API, the
development on compiler and other userspace tools side can make
the process much simpler.
I don't think many people will directly write devicetree overlays,
but generating them is not difficult since it is a defined standard.
It's harder to use than BPF, which is already really hard to use.
I don't think the ACPI situation is any better for the matter, and
a solution using DT overlays will not play nice with ACPI systems
so we just leave that part of the world out.
Can't really comment on ACPI since have not interacted with that much.
It is
simply not attractive to have tutorials or examples that will require a
reboot to work. And since a lot of people will start with those examples,
they will continue using userspace drivers for their future projects.
I agree.
I have an idea about this.
If we want to use an existing kernel drivers for dynamic devices,
something in-kernel and Linux-specific that is easy to use is
needed. I would rather look into something that enables
creation of some devices using the Linux-specific software nodes,
because *those* we can control how we configure, preferably
from configfs I suppose, but Bartosz already burnt himself trying
to use configfs once so I don't know about that specific.
Consider for example, if we have a sysfs like I suggested:
/sys/bus/gpio/gpiochip0
/sys/bus/gpio/gpiochip0/gpio0
/sys/bus/gpio/gpiochip0/gpio0/
userspace
/sys/bus/gpio/gpiochip0/gpio0/value
/sys/bus/gpio/gpiochip0/gpio1
/sys/bus/gpio/gpiochip0/gpio1/userspace
/sys/bus/gpio/gpiochip0/gpio1/value
With software nodes we can:
cd /sys/bus/gpio
cat available_gpio_drivers
i2c-gpio leds-gpio
echo leds-gpio > gpio_drivers
[/sys/bus/gpio/drivers/leds-gpio.0 appears in sysfs]
ln -s gpiochip0/gpio4 drivers/leds-gpio.0/gpios
[ probe of leds-gpio driver happens using that gpio line
now that its GPIO resources are provided]
I easily see this working for any of the drivers in
Documentation/driver-api/gpio/drivers-on-gpio.rst
Yes, it is not a solution to everything no matter how
complex a user may attach to their system, which is
the ambition of device tree overlays.
It solves the issue of dynamically probing devices
*only* using GPIO lines.
Yes: it will drive a truck through any kind of kernel integrity
and security, it provides a userspace footgun to shoot
oneself in the foot. But users want it, so hey. We point it
out. We put it as an expert option. Whatever of those.
Well, any solution we come up with, has to be for endusers
and not just a developer interface. I have suggested
maybe locking down the dt overlays to some specific
nodes which need to be declared in devicetree [0], but I am
not the maintainer of the subsystem, so many people need
to agree there, but let's see.
Btw, I do agree that there should be a sysfs based API for GPIO.
It's quite a pain when you want to not have external dependencies.
I have used the `ioctl` based API directly, but even then you end
up depending on libc (and ioctl signature is different between musl
and glibc). Additionally, all the structures and error handling just
builds up.
However these devices *will* be performant as they are
regular kernel drivers, and they *will* be able to use
interrupts in a proper way.
Yours,
Linus Walleij
[0]:
https://lore.kernel.org/all/d5bed265-1dbd-44d1-8287-8ca993624b79@xxxxxxxxxxxxxxx/
Best Regards,
Ayush Singh
