Abstracting struct ifnet

[Julian Elischer]

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 at 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,
>