Amit Shah wrote: > > Without this specific thing, which is an indicator that guest has lost > > state outside its control, the guest<->host communication is > > unreliable (even for things like "cut and paste"), so every app that > > cares has to implement a packet framing protocol with no binary data > > (to reserve an escaping byte), or with CRCs like > > PPP-over-virtio-serial, which is complicated and silly imho. If it > > were a real serial port, not emulated, that's the sort of thing apps > > would actually do (or use timeouts, which are more dubious in > > emulator-land). But I hope we're not that sadistic :-) > > I agree. So: ports have in-qemu users, they get guest_open / > guest_close callbacks and get data which they can pass on to external > apps. Looks like we're fine there?
Provided the guest_open / guest_close callbacks are synchronous with the data - so that data sent/received following guest_open exactly matches what the guest sends/receives from its beginning, that internal interface looks fine to me. We can tidy up the chardev later as needed :-) -- Jamie > > *Inband* open/close indication aren't 100% guarantees of reliability, > > but I think they raise it to the point where an app can usefully count > > on it.
