From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LyrO0-0003Cl-34
	for qemu-devel@nongnu.org; Tue, 28 Apr 2009 13:46:28 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LyrNv-00039l-Gg
	for qemu-devel@nongnu.org; Tue, 28 Apr 2009 13:46:27 -0400
Received: from [199.232.76.173] (port=47428 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LyrNv-00039f-9h
	for qemu-devel@nongnu.org; Tue, 28 Apr 2009 13:46:23 -0400
Received: from mx20.gnu.org ([199.232.41.8]:44087)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <paul@codesourcery.com>)
	id 1LyrNu-0006jj-T1
	for qemu-devel@nongnu.org; Tue, 28 Apr 2009 13:46:23 -0400
Received: from mail.codesourcery.com ([65.74.133.4])
	by mx20.gnu.org with esmtp (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1LyrNt-0001Jj-Nu
	for qemu-devel@nongnu.org; Tue, 28 Apr 2009 13:46:22 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] Re: [PATCH 9/9] Introduce VLANClientState::cleanup()
Date: Tue, 28 Apr 2009 18:46:18 +0100
References: <1239812969-8320-2-git-send-email-markmc@redhat.com>
	<200904281817.56416.paul@codesourcery.com>
	<49F73C15.7090504@us.ibm.com>
In-Reply-To: <49F73C15.7090504@us.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200904281846.19363.paul@codesourcery.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: Mark McLoughlin <markmc@redhat.com>, Anthony Liguori <aliguori@us.ibm.com>, Marcelo Tosatti <mtosatti@redhat.com>, Markus Armbruster <armbru@redhat.com>

> >> 1) Network backend is created.  As part of the configuration of the
> >> backend, a unique device identifier is associated with it.
> >> 2) A PCI device is created.
> >>   a) The PCI device creates one or more Network frontends.  Each
> >> frontend carries the device identifier and perhaps something like a port
> >> id. b) When the PCI device is destroyed, it destroys any frontends it
> >> owns.
> >
> > This sounds about right, though I'm not entirely sure what you mean
> > by "network backend". backend ~= vlan in the current implementation?
>
> Roughly, VLANClientState would be the backend.  There are too many
> details about VLAN though in VLANClientState today beyond the name.
>
> Ideally, the network backend would just consistent of an interface to
> submit packets, register buffers to receive packets, an interface to
> negotiate/enable features (GSO, checksum offload), and a means to get
> configuration information (MAC address).


Hmm, in that case I don't understand your distinction between frontend and 
backend.

> Today, you're given a VLAN and then you create a VLANClient from the
> VLAN.  That's too much implementation detail to live in the devices IMHO.

Right.

Paul