Hi On Wed, Oct 12, 2016 at 11:15 PM Dr. David Alan Gilbert <dgilb...@redhat.com> 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?) > > 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. > 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) -- Marc-André Lureau
