[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Marc-André Lureau
Subject: Re: [Qemu-devel] chardev's and fd's in monitors
Date: Wed, 12 Oct 2016 20:02:30 +0000


On Wed, Oct 12, 2016 at 11:15 PM Dr. David Alan Gilbert <address@hidden>

> 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

Marc-André Lureau

reply via email to

[Prev in Thread] Current Thread [Next in Thread]