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

[Marc-André Lureau]

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?)


>
> 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