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<adr...@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,
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
