Hi Jakub,

On 05/23/2013 11:59 AM, Jakub Jermar wrote:
> Yesterday, we (as in JS, MS and me) briefly touched some existing issues
> with using the serial port driver for both reading and writing at the
> same time. Martin, I thought this topic deserves some more attention, so
> I wanted to state what problems I know about so that you can check your
> own findings and add to the list, if you know of some other issues:
> 
> - #508 Parallel sessions don't mix well with call forwarding
> 
> This problem is making it impossible to have a parallel session opened
> to a serial service using `loc_service_connect()' on the respective
> _service_ path. However, due to the way this bug works, it is possible
> to establish the parallel session using `devman_device_connect()` on the
> respective _device_ path.
I always tried using loc_service_connect and didn't have time to look
into the problem when using parallel sessions. Thanks for explanation of
the underlying problem.

> Note that the parallel sessions are one of the two possible ways to
> access the device for both reading and writing at the same time. The
> fibrils executing the char_dev_read() call can block inside the ns8250
> driver, while fibrils executing the char_dev_write() can proceed without
> being blocked by the readers.
> 
> The other way is establishing two separate serialized sessions to the
> serial service. One sessions will be used for reading and the other for
> writing to the device.
> 
> - The ns8250 does not support more than one connected clients.
> 
> I allowed more clients to be connected to ns8250 in:
> 
> http://bazaar.launchpad.net/~jakub/helenos/slip/revision/1818
> 
> - There appears to be a bug in QEMU, which shows when you want to
> redirect the serial port to a pipe on the host using something like:
> 
> $ mkfifo /tmp/serialpipe
> $ qemu ... -seril pipe:/tmp/serialpipe
> 
> https://bugs.launchpad.net/qemu/+bug/1181796
I think I tried a similar modification of ns8250 to access the device
using two separate sessions, but it is possible I hit the QEMU bug (or
that I had a bug in my client code). AFAIR I always used a program that
might have sent more than 16 bytes as a response to the data it read (I
used -serial pipe:... as well). It may have happened that I just closed
the QEMU window when I saw no response in my HelenOS program, thereby
not noticing it blocking the whole VM. Frankly, I have not tried
determining the cause why it didn't work for me and moved on to process
other items on my TODO list.

> Now, do you know of more issues that would prevent parallel readers and
> writers?
No. The above seems to be plausible with respect to what I saw/remember.
Unfortunately, I won't be able to look at it again in the near future.

Martin Sucha


_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel

Reply via email to