Date: Wed, 27 Nov 2002 16:18:46 -0800 From: Luigi Rizzo <rizzo@icir.org> To: Marko Zec <zec@tel.fer.hr> 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: <20021127161846.A98188@xorpc.icir.org> In-Reply-To: <3DE4FD66.78DE9AEB@tel.fer.hr>; from zec@tel.fer.hr on Wed, Nov 27, 2002 at 06:14:14PM %2B0100 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > 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. 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. cheers luigi 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?20021127161846.A98188>