Date: Thu, 28 Nov 2002 09:28:49 +0100 From: Marko Zec <zec@tel.fer.hr> To: Luigi Rizzo <rizzo@icir.org> Cc: Julian Elischer <julian@elischer.org>, "M. Warner Losh" <imp@bsdimp.com>, 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? Message-ID: <3DE5D3C1.4B309269@tel.fer.hr> References: <20021127.002657.21921523.imp@bsdimp.com> <Pine.BSF.4.21.0211262328210.57127-100000@InterJet.elischer.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DE5D3C1.4B309269>