I would still fix this upstream and only workaround devices blacklisted with a
I don't see how this would be possible. The issue with poll() lies in
the kernel, not the device. I guess a patched kernel could somehow
indicate that it supports poll() for writing, like an attr on the device
OK, there's probably a lot I don't know about rpmsg, and I don't
currently have a device running this setup.
I don't understand; what is the race condition? oFono plus another
client trying to use the same device?
This reminds me also why RPMSG is not actually exported as a socket in the
first. Creating a device node first and then using it later is always prone to
race conditions. An alternative is to open the control character device and
turn it into a proper pipe for QMI. I would like to see some proper fixes in
the RPMSG subsystem to allow for proper handling by a telephony daemon.
How would the control device become a QMI pipe? As it stands today, I
think all you can do with it is open and do that ioctl
How is the rpmsg endpoint char device not a proper pipe for QMI,
compared to what you're envisioning?
It sounds like the userspace rpmsg system is not mature enough to do
this the way you want. Will we have to wait until then to merge this?
P.S. These patches should probably add the new subsystems to the hotplug
code, not just the enumeration at startup.
ofono mailing list