Re: [PATCH 0/8] gpiolib: add an ioctl() for monitoring line status changes

[Enrico Weigelt, metux IT consult]

Hi,

>> Oh, no, I've been afraid that this would be coming ... desktop bus in
>> embedded system is a real nightmare. (yes, some people are even insane
>> enough to put that thing on an public IP interface and so make critical
>> machinery like cards easily remote controllable by average school kids)
> 
> Nah, you're overreacting, nobody is putting anything on the network.

Maybe you've just missed that (maybe better for mental health ;-)), but
people actually do put desktop bus on open networks. Chrysler/Harmann
are an famous example (rendering the cars easily remote-controllable)
I've had lots of similar cases w/ my clients. Whats going on in critical
industries like automotive or medical often is a real nightmare. One of
the reasons why I only buy old cars and do a careful inspection of
physicians before allowing them to treat me or my family.

IMHO, we should be careful about not encouraging folks out there to do
silly things, just because they look so easy. (embedded development
isn't entirely easy)

> Most of my work isn't in upstream kernel development - it's actually
> launching CE products. And it's been a long time since I've worked
> with a client that could be convinced not to use systemd and dbus on
> an embedded system. 

Yeah, same problem here. But actually, it's easier than one might think:
let them run into a scenario where that malware really does horrible
things and let the client drive against the wall. Some will learn,
others won't - just let evolution optimize that :p

> This just makes things so easy for people writing
> high-level application code that it's become de-facto standard -
> whether we like it or not.

Yeah, "hilevel" code, that completely ignores vital aspects of the
machine it then runs on, eg. RT or memory constraints. Seen that so
many times. Emperical experience tells: sooner or later it will go
nuts and things go horribly wrong. The unplesant question just is: how
many people have get hurt or killed in the process.

Lennartware isn't the only problem here, but also ancient and completely
unmaintained vendor kernels, patched-to-deah by rookies (eg. ublox).
OTOH, the positive side, eg. if I really need to get a *new* car, I'd
pick one where I can disable surveillance stuff like "ecall" easily :p

In general, what those industries completely ignore is maintainability
and stability. There, this only exists on the paper (cubic meters of
papers that formally look nice, but don't really tell anything about
the *actual* important facts) - formally proven bullshit.

I've made the personal decision that I don't wanna become yet another
Edward Teller, neither do I wanna allow some BSG-type scenario. That's
the reason I'm spending so much time in this discussion.

> This is just your personal anecdote. I could bring up several examples
> of good implementations of event-based, dbus-oriented systems all
> right. Bad programmers don't make tools they're using bad.

Problem is: good programmers who can really deal with those concepts
are hard to find. And those systems usually are hard to test. Desktop
bus is magnitudes more complex than isolated FSMs.

Within the last decades, I never had a single case where desktop bus had
been the superior choice (actually, only few cases where purely event-
driven architecture was a good idea).

> I want to add this
> new feature to allow for creating a central entity controlling GPIO
> lines in the user-space. In case of sysfs - IT IS such a central
> entity except that it lives in the kernel. It doesn't need to be
> notified about changes in line properties.

I'm still wondering why exactly one would want such an central entity
in userspace and then letting it talk to others via desktop bus. At
least in critical embedded systems, not talking about self-knittet
hobby projects. Seems those ideas originate from people who don't know
what the OS/Kernel is for :p

Actually, I had a case where somebody attemted to do so (folks who tried
linux embedded development from a windows machine :o). Fortunately,
before they could write their planned "GPIO HAL" (several 10kLoc for
just doing some trivial sysfs ops), I've configured the lines to the
proper drivers in DT (basically, just some LEDs, inputs, rs485 signal
lines, etc). Later on they started to write some "HAL" for LEDs,
inputs, rs485 ... the manager of neighboring department on the other
end of the room then ask me: "don't they know that they've got an
operating system" ;-)

Seriously, we shouldn't do everything that some strange folks are asking
for, just to make them happy. We don't wanna desktop bus in the kernel,
do we ? :p

By the way: we *do* need some improvements for PLC-like applications:
Highlevel provisioning of platform devices, eg. configure which devices
are attached to certain interfaces in an specific installation, so the
applications don't ever need any knowledge about that, but just talk
to specific devices.

Most of what's needed (on kernel side) is already there: DT overlays.
Just yet have to get this working on non-DT (eg. ACPI platform).

In fact that's already in my pipeline, also for other purposes, eg.
replace simple board or mfd drivers by just a DT snippet. Yet lacked the
time to work out a suitable way for mixing DT and ACPI and allowing DT
to override ACPI. But that's a topic for a completely different thread.


--mtx--

---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@xxxxxxxxx -- +49-151-27565287