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.



ofono mailing list

Reply via email to