On Thu, Jan 23, 2014 at 04:45:34PM -0800, Luigi Rizzo wrote:
> On Thu, Jan 23, 2014 at 4:43 PM, Ben Pfaff <b...@nicira.com> wrote:
>
> > On Fri, Jan 24, 2014 at 01:29:32AM +0100, Daniele Di Proietto wrote:
> > > I'll just attach the patch (just for a quick preview, it is not ready
> > jet)
> > > that builds the userspace components for the kernel datapath in FreeBSD.
> > We
> > > provide some linux functionalities (netlink and epoll) through wrappers
> > > (not included here) so that LINUX_DATAPATH is true. What we may need is a
> > > better way to understand which features are present to exclude some
> > blocks
> > > inside LINUX_DATAPATH.
> >
> > From reading this, it looks like the BSD kernel datapath port also
> > uses Netlink as the communication channel to the kernel. Is that
> > correct?
> >
>
> correct. daniele implemented netlink generic sockets
> for FreeBSD as a kernel module as part of the work.
OK, that explains why there are interesting boundaries being crossed
here.
How about this:
- Replace LINUX_DATAPATH by NETLINK_DATAPATH, since that seems
to describe the relationship better.
- Instead of (LINUX_DATAPATH && !HAVE_IF_DL), write just
__linux__. In the cases I looked at, the interface didn't
seem too likely to be of interest outside Linux.
- Where individual features seem to be sensibly testable, do
that.
- If the FreeBSD kernel datapath port makes it to upstream
FreeBSD, or otherwise achieves some kind of widespread
adoption, then we might eventually want to rename dpif-linux
to dpif-netlink.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
