From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44169) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1enoS3-0007Hu-9G for qemu-devel@nongnu.org; Mon, 19 Feb 2018 11:38:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1enoS0-0000oi-Lr for qemu-devel@nongnu.org; Mon, 19 Feb 2018 11:38:03 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:47586 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1enoS0-0000oY-He for qemu-devel@nongnu.org; Mon, 19 Feb 2018 11:38:00 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 120C1402314E for ; Mon, 19 Feb 2018 16:37:49 +0000 (UTC) References: <1519031728-9850-1-git-send-email-thuth@redhat.com> <1519031728-9850-8-git-send-email-thuth@redhat.com> <7c298a4a-97cd-4b7a-d170-b70ab2970aac@redhat.com> From: Thomas Huth Message-ID: Date: Mon, 19 Feb 2018 17:37:41 +0100 MIME-Version: 1.0 In-Reply-To: <7c298a4a-97cd-4b7a-d170-b70ab2970aac@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v1 7/8] net: Add a new convenience option "-n" to configure default/on-board NICs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , qemu-devel@nongnu.org, Jason Wang , "Dr. David Alan Gilbert" Cc: Eric Blake , Markus Armbruster , Stefan Hajnoczi On 19.02.2018 17:20, Paolo Bonzini wrote: > On 19/02/2018 10:15, Thomas Huth wrote: >> The legacy "-net" option can be quite confusing for the users since most >> people do not expect to get a "vlan" hub between their emulated guest >> hardware and the host backend. But so far, we are also not able to get >> rid of "-net" completely, since it is the only way to configure on-board >> NICs that can not be instantiated via "-device" yet. It's also a little >> bit shorter to type "-net nic -net tap" instead of "-device xyz,netdev=n1 >> -netdev tap,id=n1". >> >> So what we need is a new convenience option that is shorter to type than >> the full -device + -netdev stuff, and which can be used to configure the >> on-board NICs that can not be handled via -device yet. Thus this patch now >> provides such a new option "-n": It adds an entry in the nd_table to >> configure a on-board / default NIC, creates a host backend and connects >> the two directly, without a confusing "vlan" hub inbetween. > > Sorry for the bikeshedding, but... perhaps "-n" is a bit bold. While I > initially couldn't come up with a better one, after putting some thought > into it "-nic" came to mind. There's precedent in naming the option for > the *front-end* device that it creates, whereas the arguments define > either the front-end (e.g. "model") or the back-end; see for example > "-drive". "-nic tap,model=e1000" and "-nic none" both make nice sense. Actually, I like the idea with "--nic", that indeed makes sense here and is still quite short to type. I'll use that in v2 (but I'll wait one or two more days for some more review comments before sending that out). Thomas