[ovs-dev] RFC: the meaning of LINUX_DATAPATH and HAVE_IF_DL

[Ben Pfaff]

On Thu, Jan 23, 2014 at 4:55 PM, Ben Pfaff <blp at nicira.com> wrote:
> On Thu, Jan 23, 2014 at 04:45:34PM -0800, Luigi Rizzo wrote:
>> On Thu, Jan 23, 2014 at 4:43 PM, Ben Pfaff <blp at 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.


Does this make sense to everyone?
-- 
"I don't normally do acked-by's.  I think it's my way of avoiding
getting blamed when it all blows up."               Andrew Morton