Re: [Qemu-devel] chardev's and fd's in monitors

[Dr. David Alan Gilbert]

* Marc-André Lureau (address@hidden) wrote:
> Hi
> 
> On Wed, Oct 12, 2016 at 11:15 PM Dr. David Alan Gilbert <address@hidden>
> wrote:
> 
> > Hi,
> >   I had a look at a couple of readline like libraries;
> > editline and linenoise.  A difficulty with using them is that
> > they both want fd's or FILE*'s; editline takes either but
> > from a brief look I think it's expecting to extract the fd.
> > That makes them tricky to integrate into qemu, where
> > the chardev's hide a whole bunch of non-fd things; in particular
> > tls, mux, ringbuffers etc.
> >
> 
> We could restrict readline usage to chardev with fd? But even with that,
> how would it be compatible with mux? It would have to somehow steal/restore
> the chardev fd. Alternatively, we could have a "fd pipe"/socketpair chardev
> frontend compatible with any chardev. Sounds contrived though, but it
> should work, and probably not so much code. (qemu_chr_new_fd_fe?)

Right; you'd still have to be careful about where the code ran that
stuffed it down that fd; for example I was thinking that maybe
I could connect editline to a pipe, and then just add a handler
that streamed that out to the chardev; but I worry that if, in the main
thread, I was to pass input to editline that caused it to output a huge
amount (say a big tab complete or a max-len filename) then it could deadlock
because the thing emptying the pipe wouldn't get run until the main loop
returned.

editline does have an 'el_push' so you could avoid having a real fd for it's
input (or at least an fd that ever does anything) and just call el_push
to stuff characters into it's input queue.

> >
> > If we could get away with just a FILE* then we could use fopencookie,
> > but that's GNU only.
> >
> > Is there any sane way of shepherding all chardev's into having an
> > fd?
> >
> 
> Ah that would be nice! But I think the point is to stay in userspace (and
> avoid extra copy, context switch, or extra fds). Otherwise, it feels like
> the whole chr interface could be a socketpair + a thin layer for events,
> that would simplify things indeed.

Well that would be nice :-)  I don't have much sympathy for saving on copies
and context switches at the bandwidth the monitor is going at.

> > Once you had those then you could also use them in a separate thread.
> >
> >
> You can already use chardev in seperate thread, but I don't know to which
> extent (see add_handlers_full for completely seperate thread, locking for
> write for multi-writer, I suppose s->chr_read is called from the
> dispatching context and is responsability for frontend callback to lock
> properly)

Oh that's fancy and new.   It would be fun to run a monitor in a different
thread with that; or use it to drain an output fd.
But would you trust multiple threads to drive the two different parts of a mux?

Dave

> -- 
> Marc-André Lureau
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK