From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N6lti-0005NZ-C8 for qemu-devel@nongnu.org; Sat, 07 Nov 2009 09:04:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N6ltd-0005MN-KA for qemu-devel@nongnu.org; Sat, 07 Nov 2009 09:04:09 -0500 Received: from [199.232.76.173] (port=59492 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N6ltd-0005MK-At for qemu-devel@nongnu.org; Sat, 07 Nov 2009 09:04:05 -0500 Received: from mail-yw0-f176.google.com ([209.85.211.176]:52427) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N6ltc-0006tg-Qj for qemu-devel@nongnu.org; Sat, 07 Nov 2009 09:04:04 -0500 Received: by ywh6 with SMTP id 6so1586636ywh.4 for ; Sat, 07 Nov 2009 06:04:04 -0800 (PST) Message-ID: <4AF57E51.20606@codemonkey.ws> Date: Sat, 07 Nov 2009 08:04:01 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu References: <1257294485-27015-1-git-send-email-aliguori@us.ibm.com> <20091105163702.GC21630@shareable.org> <4AF30129.7080203@us.ibm.com> <200911051820.48878.arnd@arndb.de> <4AF3154F.8090901@redhat.com> <4AF32E78.1040103@us.ibm.com> <4AF3CED1.7080207@redhat.com> <4AF43064.9080007@us.ibm.com> <4AF53A6E.6050304@redhat.com> In-Reply-To: <4AF53A6E.6050304@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Mark McLoughlin , Anthony Liguori , Arnd Bergmann , Arnd Bergmann , Dustin Kirkland , Juan Quintela , qemu-devel@nongnu.org, Michael Tsirkin Avi Kivity wrote: >> Running qemu directly from the command line is absolutely an >> important use case. > > Where does this requirement come from? For most of qemu's lifetime, this was the only option. The current graphical front ends only support a subset of qemu's features and qemu's target architecture types. qemu is more than just KVM accelerated x86 guests. I also disagree that only developers are interested in using qemu directly. There are a lot of power users who also use qemu directly. >> A desktop user should not need things like libvirt and virt-manager. > > virt-mananger is miles ahead of where you're aiming. > > I'd like to a proper same-process graphical UI client. But I don't > think this list is the place to create it. I don't think we have > either the skills or the patience; also there's room for more than > one. We should focus on making it easy to write one; that involves > exporting the display surface in an embeddable non-vnc way and making > everything controllable via QObjects (perhaps through the monitor, > perhaps through bindings for scripting languages. > >> If it cannot be fixed in the kernel, we'll have to work around it in >> userspace. We can introduce our own spawn() function that works by >> fork()'ing very early and listening on a socketpair. This will sit >> reading from the socket waiting for commands to exec. Using a unix >> socket, we can pass fds that get inherited which we can't do with >> system(). > > Or we can admit to ourselves that qemu is too complex to be directly > controlled by a user. It's good to have an easy to use command line > for developers and power users; I'd welcome -net bridge as one of > them. But we shouldn't try to invent access control systems or > install suid helpers. Mainstream use needs to involve some management > agent which does authentication and privileged configuration (it was > already established that the the hotplug equivalent of -net bridge is > racy if any configuration is required). I disagree about the role a management app should play. For a casual user, a management app really should not be needed. Regards, Anthony Liguori