From owner-freebsd-arch Wed Nov 27 7:56:32 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 4B94837B401 for ; Wed, 27 Nov 2002 07:56:31 -0800 (PST) Received: from mail.iskon.hr (inje.iskon.hr [213.191.128.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 7169043E88 for ; Wed, 27 Nov 2002 07:56:25 -0800 (PST) (envelope-from zec@tel.fer.hr) Received: (qmail 10704 invoked from network); 27 Nov 2002 16:56:23 +0100 Received: from zg03-114.dialin.iskon.hr (HELO tel.fer.hr) (213.191.135.115) by mail.iskon.hr with SMTP; 27 Nov 2002 16:56:23 +0100 Message-ID: <3DE4EB22.39D9BD07@tel.fer.hr> Date: Wed, 27 Nov 2002 16:56:18 +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> Content-Type: text/plain; charset=iso-8859-2 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 Tue, Nov 26, 2002 at 11:29:04PM -0800, Julian Elischer wrote: > ... > > which is why I think we should reserve some fields now... > > I don't see much need for it. > > We have a nice infrastructure (m_tags) to carry info together with > mbufs. ifnet's can be easily extended in much the same way used by > the bridging code (by using the if_index to point into external > arrays containing specific extensions); processes/threads/kseg have > the extra pointer/room for custom schedulers... I think the > usual suspects are all covered. This concepts are unfortunately not applicable in case of virtualization / cloning of the entire network stack. As each network stack instance has its own set of arrays a'la ifindex2ifnet[], the if_index often has the same value across multiple stack instances, for different interfaces residing in different stacks. The bridging code was especially problematic for virtualization just because of this concept of using external arrays for storing bridging specific data, indexed by if_index. In case of network stack virtualization, the m_tags infrastructure doesn't help much either. The virtualization concept simply requires an additional pointer in both struct ifnet and proc. The issue with the bridging code is currently resolved by extending the struct arpcom to hold bridging specific information instead of using the external ifp2sc array, though I'm not sure this is the most appropriate solution either... Marko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message