On 2013-02-21 18:10, Paolo Bonzini wrote: > Il 21/02/2013 17:29, Jan Kiszka ha scritto: >> In this context, I'd like to recall a detail: Real-time prioritization >> of those I/O threads will most probably require locking with >> prio-inversion avoidance (*). In that case external libs without a >> chance to tune or replace their internal locking (like glib) will be a >> no-go for those kind of I/O threads. >> >> The glib mainloop might be fine for all the rest, but we will likely >> also need event loops with RT-compatible locking. So this refactoring >> should keep the door open for alternative implementations. > > Yes, this refactoring is fine. It doesn't use the glib mainloop any > more than before. AioContext is fine as an RT-compatible event loop. > You can use both as a GSource or manually from a separate thread. > > What would be more problematic is the chardev flow control patches, > which use the glib main loop directly. I don't recall your KVM forum > presentation---did you need RT prioritization of the serial port too?
Not in my use case (that was the RTC). I didn't come across a scenario where you have to emulated a serial port with real-time constraints so far but I would not exclude it. Hmm, think of serial over LAN: UART device is remote, virtualized legacy system shall talk to it as if it was locally connected, and that in a timely manner. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux
