From owner-freebsd-arch Wed Nov 27 16:19: 1 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 5996337B401; Wed, 27 Nov 2002 16:19:00 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5C9243EAF; Wed, 27 Nov 2002 16:18:59 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.3/8.12.3) with ESMTP id gAS0IlTO098321; Wed, 27 Nov 2002 16:18:47 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.3/8.12.3/Submit) id gAS0IkHp098320; Wed, 27 Nov 2002 16:18:46 -0800 (PST) (envelope-from rizzo) Date: Wed, 27 Nov 2002 16:18:46 -0800 From: Luigi Rizzo To: Marko Zec 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? Message-ID: <20021127161846.A98188@xorpc.icir.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3DE4FD66.78DE9AEB@tel.fer.hr>; from zec@tel.fer.hr on Wed, Nov 27, 2002 at 06:14:14PM +0100 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 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