From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38224) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buPjg-0002zX-IC for qemu-devel@nongnu.org; Wed, 12 Oct 2016 16:02:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buPjf-0003hk-8X for qemu-devel@nongnu.org; Wed, 12 Oct 2016 16:02:44 -0400 Received: from mail-lf0-x22c.google.com ([2a00:1450:4010:c07::22c]:33488) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buPje-0003hG-S1 for qemu-devel@nongnu.org; Wed, 12 Oct 2016 16:02:43 -0400 Received: by mail-lf0-x22c.google.com with SMTP id x79so95332600lff.0 for ; Wed, 12 Oct 2016 13:02:42 -0700 (PDT) MIME-Version: 1.0 References: <20161012191502.GC16187@work-vm> In-Reply-To: <20161012191502.GC16187@work-vm> From: =?UTF-8?B?TWFyYy1BbmRyw6kgTHVyZWF1?= Date: Wed, 12 Oct 2016 20:02:30 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] chardev's and fd's in monitors List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" , qemu-devel@nongnu.org, berrange@redhat.com, armbru@redhat.com Hi On Wed, Oct 12, 2016 at 11:15 PM Dr. David Alan Gilbert 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) --=20 Marc-Andr=C3=A9 Lureau