From owner-freebsd-arch Thu Nov 28 0:29: 3 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD04137B401 for ; Thu, 28 Nov 2002 00:29:01 -0800 (PST) Received: from mail.iskon.hr (inje.iskon.hr [213.191.128.16]) by mx1.FreeBSD.org (Postfix) with SMTP id BFC1D43EC2 for ; Thu, 28 Nov 2002 00:29:00 -0800 (PST) (envelope-from zec@tel.fer.hr) Received: (qmail 10521 invoked from network); 28 Nov 2002 09:28:48 +0100 Received: from zg03-107.dialin.iskon.hr (HELO tel.fer.hr) (213.191.135.108) by mail.iskon.hr with SMTP; 28 Nov 2002 09:28:48 +0100 Message-ID: <3DE5D3C1.4B309269@tel.fer.hr> Date: Thu, 28 Nov 2002 09:28:49 +0100 From: Marko Zec X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: Julian Elischer , "M. Warner Losh" , phk@critter.freebsd.dk, rwatson@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: ABIs and 5.x branch: freeze kernel module ABI at 5.0 or 5.1? References: <20021127.002657.21921523.imp@bsdimp.com> <20021126234344.A59511@xorpc.icir.org> <3DE4EB22.39D9BD07@tel.fer.hr> <20021127081054.A76965@xorpc.icir.org> <3DE4FD66.78DE9AEB@tel.fer.hr> <20021127161846.A98188@xorpc.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Luigi Rizzo wrote: > On Wed, Nov 27, 2002 at 06:14:14PM +0100, Marko Zec wrote: > ... > > if_index is not only used for accessing ifindex2ifnet[], but some other arrays as > > well, such as ifnet_addrs[] or ipx_ifaddr[]. If we want to have fully independent > > network stacks with overlapping addressing schemes, the simplest and cleanest > > approach is a clear separation of all those arrays containing any type of > > addressing information. Otherwise, many parts of the code traversing through those > > I still do not follow what you have in mind. > > You need to link the descriptor for the virtualized device to the descriptor > for the actual piece of hardware, and vice-versa. For the former you > are ok with a pointer, but for the latter you cannot use a pointer because > each virtual network stack (you can have multiple) would need its own. > A thing such as if_index is actually exactly what you need because > you can use it to reach different info in the different contexts. > > If you are saying that you need multiple ifnet_addrs[] and ifindex2ifnet[] > etc., one per virtual network stack, yes that is true, but has nothing > to do with the device driver which are totally unaware of their presence. Now I do not follow :) The virtualization framework actually doesn't touch device drivers at all. There are no such things as "virtualized devices" and "actual pieces of hardware" as you are suggesting. One physical device (and its entire _unmodified_ driver) can reside in one and only one virtual stack image at a time. For other network stack instances, the access to the outside world via the link layer can be provided by _bridging_ the real (ethernet) device with an entirely independent and stub virtual ethernet device, with it's own struct arpcom and ifnet and it's own MAC address. Otherwise the descriptors of the "real" and "virtual" interfaces are normally not linked in any way - each interface is fully independent as it should be (except vlan and friends, but that's another story). > > > Same for struct proc (we used a few spare bytes in > > > -stable' struct proc exactly in this way, storing an equivalent of > > > if_index, and going to an external structure through it to access > > > extension information for our proportional share scheduler). > > > There are surely minor performance issues with this (you have > > > to go through a base_ptr+index whenever you access the extra info > > > instead of using a direct pointer), but in many cases this disappears > > > in the noise. > > > That's exactly what I've done in the original 4.7-R patch. However, > > it is clear that using a dedicated pointer directly in struct proc > > instead of having an index to external array of pointers would be > > not only more efficient solution, but also probably a more readable > > actually the pointer would be a nightmare in the case of multiple > virtual network stacks, or jails, or virtual systems, because you need > this "pointer" to dereference to different things depending on the > virtual instance you are working on. I'm not sure what you're aiming at - only _one_ pointer is needed to a struct which servers as a container for all the virtualized symbols. If one day the virtualization approach would become more modular, one pointer could still be sufficient, but now to a different structure defining to which virtualized resources the process is bound to (network stack, jail-style process group, CPU, VM, swap etc.) > Just re-think of the if_index: a single field could be used to extend > the ifnet with bridging, ipx, multiple ip addresses, etc. all at the > same time and without any ABI issue. Just the contrary - in my view preserving ABI is much simpler if you have independent indexing of network interfaces for each virtual image. Which reminds me on another thing I almost forgot - there is a sysctl in net/if_mib.c that relies on ifnet_addrs to be monolithic - one reason more why the approach of holding pointers to interfaces belonging to different virtual images in a _single_ array would be difficult to implement (you would have to skip the entrys not belonging to the current virtual image, but at the same time pretend the interface indexes are not skipped...) Marko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message