From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55290) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buiET-0002Et-Jv for qemu-devel@nongnu.org; Thu, 13 Oct 2016 11:47:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buiEO-0004TJ-Ni for qemu-devel@nongnu.org; Thu, 13 Oct 2016 11:47:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43588) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buiEO-0004S8-Dh for qemu-devel@nongnu.org; Thu, 13 Oct 2016 11:47:40 -0400 Date: Thu, 13 Oct 2016 16:47:35 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20161013154734.GC2169@work-vm> References: <20161012191502.GC16187@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: 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: =?iso-8859-1?Q?Marc-Andr=E9?= Lureau Cc: qemu-devel@nongnu.org, berrange@redhat.com, armbru@redhat.com * Marc-Andr=E9 Lureau (marcandre.lureau@gmail.com) wrote: > Hi >=20 > On Wed, Oct 12, 2016 at 11:15 PM Dr. David Alan Gilbert > wrote: >=20 > > 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. > > >=20 > 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/res= tore > the chardev fd. Alternatively, we could have a "fd pipe"/socketpair cha= rdev > 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 deadl= ock 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 i= t'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? > > >=20 > Ah that would be nice! But I think the point is to stay in userspace (a= nd > avoid extra copy, context switch, or extra fds). Otherwise, it feels li= ke > 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 cop= ies 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 whi= ch > extent (see add_handlers_full for completely seperate thread, locking f= or > 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 differen= t 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 > --=20 > Marc-Andr=E9 Lureau -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK