Abstracting struct ifnet

[Marcel Moolenaar]

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.

FYI,

-- 
Marcel Moolenaar
marcel at xcllnt.net