Date: Tue, 21 Feb 2012 22:08:01 -0800 From: Julian Elischer <julian@freebsd.org> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: Adrian Chadd <adrian@freebsd.org>, Brooks Davis <brooks@freebsd.org>, Juli Mallett <jmallett@freebsd.org>, net@freebsd.org, Konstantin Belousov <kostikbel@gmail.com>, Luigi Rizzo <rizzo@iet.unipi.it> Subject: Re: Abstracting struct ifnet Message-ID: <4F448641.8070403@freebsd.org> In-Reply-To: <1F812CB2-152F-47AF-9952-6AEAC6D95547@xcllnt.net> References: <338757D1-6B1E-49CF-983F-5D5851066FD3@xcllnt.net> <20120220231601.GA51310@lor.one-eyed-alien.net> <20120221001552.GA60050@onelab2.iet.unipi.it> <CAJ-Vmoni1DHpxet08=JWSDGLFBP7MHO4-WDBLwX9vGxibR=EDA@mail.gmail.com> <CACVs6=_kTVC7tnsPJqgRq3VtUaSefkunVU8JetTdsXjGCmUT7A@mail.gmail.com> <CAJ-Vmo=T28t0XBmzmkNjOEA6wJ-Ub3Bc9DiWu1upDpBt8bM=XA@mail.gmail.com> <CACVs6=9efUMQHTr9RH9SHm=Apo0PV7NeKcwFyV%2B2k9HCFNjS9g@mail.gmail.com> <20120221090821.GE55074@deviant.kiev.zoral.com.ua> <1F812CB2-152F-47AF-9952-6AEAC6D95547@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/21/12 9:13 AM, Marcel Moolenaar wrote: > On Feb 21, 2012, at 1:08 AM, Konstantin Belousov wrote: > >> On Mon, Feb 20, 2012 at 06:42:15PM -0800, Juli Mallett wrote: >>> On Mon, Feb 20, 2012 at 18:34, Adrian Chadd<adrian@freebsd.org> wrote: >>>> Is the target though _binary_ compatibility? Just having a blessed >>>> method of doing accessor method things will buy more source >>>> flexibility. The KBI can stay the same in the default case and IMHO >>>> this kind of thing gives developers more power to do smart invariant >>>> and debugging things. >>> KBI compatibility requires very little discipline and makes loadable >>> modules for network drivers much less hellish. Inlines, macros and >>> full visibility of ifnet in -current may be useful, but unless there's >>> a performance reason for doing so, retaining KBI compatibility *and* >>> the ability to merge ifnet changes to -stable sounds pretty nice to >>> me. > *snip* >> You could take a look how mutexes or vm_page_locks are handled, >> giving inlines for kernel proper and stable KBI for modules. > > A stable KBI is what we'll be aiming for at Juniper. We're working > towards a kernel proper without any networking, the FreeBSD network > stack as a module, the Juniper network stack as a module and H/W > network drivers as modules. The network drivers and how they talk > to the network stack is the big piece we still had to flesh out. > > Dynamic loading and unloading of network stack modules is not a goal, > but we do want to be able to pre-load the network stack that we want > to use and not have to worry about matching the H/W network drivers > with the stack of choice. > > Inlines for the kernel proper and a stable KBI for modules seems to > match everyone's objectives/concerns. We'll definitely take a look > at the mutexes and vm_page_locks. I've often wonderd if the vnet changes could be extended to allow not only instances of a single stack, but completely different stacks. > FYI, >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F448641.8070403>