Hi Joey, >> I would still fix this upstream and only workaround devices blacklisted with >> a quirk. > > 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 node. > > OK, there's probably a lot I don't know about rpmsg, and I don't currently > have a device running this setup.
it is a kernel bug for sure and should be fixed there. Not supporting POLLOUT properly is just bad. >> 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. > I don't understand; what is the race condition? oFono plus another client > trying to use the same device? > > 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 > (https://github.com/torvalds/linux/blob/60cc43fc888428bb2f18f08997432d426a243338/drivers/rpmsg/rpmsg_char.c#L451). > 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? Sadly, I have seen this before where it is not fully thought through. It could be really great and race free, but seems right now it is only half done. So I would start improving RPMSG subsystem. We can look into working around older kernels (with tons of comments on why), but first I would like to see if we can do this properly. So that we don’t have to workaround our own workaround once the kernel behaves better. Regards Marcel _______________________________________________ ofono mailing list ofono@ofono.org https://lists.ofono.org/mailman/listinfo/ofono
