Date: Wed, 27 Nov 2002 16:56:18 +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: <3DE4EB22.39D9BD07@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DE4EB22.39D9BD07>