All,
Juniper is in the final phases of creating a clean separation
between FreeBSD and Junos, so as to make upgrades of FreeBSD
easier. This also allows Juniper to track -current and be more
active FreeBSD contributors.
To that end, we have a short-term and hopefully short-lived
problem to solve, which is the ability to use FreeBSD's network
drivers against the Junos network stack. As some may know, the
Junos network stack has split up struct ifnet into a physical
and logical component, called ifdev and iflogical.
We've tried a few approaches to bridge the gap between ifnet
on the one hand and ifdev and iflogical on the other and found
that abstracting ifnet and using accessor functions is the
best way to allow us to use FreeBSD drivers with the Junos
network stack, while retaining the ability to use them with
the FreeBSD stack.
FreeBSD is also looking at breaking up ifnet and with that in
mind, I was wondering if there would be any resistance to
changing network drivers to use accessor functions or macros
instead of direct pointer dereferences?
For example, do something like:
Index: if_fxp.c
===================================================================
--- if_fxp.c (revision 231178)
+++ if_fxp.c (working copy)
@@ -823,13 +823,14 @@
}
if_initname(ifp, device_get_name(dev), device_get_unit(dev));
- ifp->if_init = fxp_init;
- ifp->if_softc = sc;
- ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST;
- ifp->if_ioctl = fxp_ioctl;
- ifp->if_start = fxp_start;
+ if_set_init(ifp, fxp_init);
+ if_set_softc(ifp, sc);
+ if_set_flags(ifp, IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST, 0);
+ if_set_ioctl(ifp, fxp_ioctl);
+ if_set_start(ifp, fxp_start);
- ifp->if_capabilities = ifp->if_capenable = 0;
+ if_set_capabilities(ifp, 0);
+ if_set_capenable(ifp, 0);
/* Enable checksum offload/TSO for 82550 or better chips */
if (sc->flags & FXP_FLAG_EXT_RFA) {
Such a scheme, while initially touching a lot of driver,
would make it easier to break up ifnet *and* also make it
easier to hide ABI/API changes from driver vendors (esp.
when the accessor functions are non-inlined functions and
not macros or inlines). This is particularly useful for
Juniper, where we have worked towards network stacks as
(pre-)loadable modules so as to help with migration and
validation.
Thoughts, feedback and suggestion are welcome,
--
Marcel Moolenaar
mar...@xcllnt.net
_______________________________________________
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"
