[ovs-dev] datapath-windows: Could we rename the files please?

Saurabh Shah ssaurabh at vmware.com
Wed Aug 6 18:07:30 UTC 2014

My 2 cents, I am not in favor of redoing the directory structure in the
anticipation of it becoming more complex. When/If it becomes complex, we
can do the re-structuring. I don¹t see any need to do it right now.


From:  Nithin Raju <nithin at vmware.com>
Date:  Wednesday, August 6, 2014 at 10:52 AM
To:  Samuel Ghinet <sghinet at cloudbasesolutions.com>
Cc:  "dev at openvswitch.org" <dev at openvswitch.org>
Subject:  Re: [ovs-dev] datapath-windows: Could we rename the files please?

>On Aug 6, 2014, at 2:48 AM, Samuel Ghinet <sghinet at cloudbasesolutions.com>
> wrote:
>> Hello Nithin,
>> I'd like to highlight two points here:
>> 1. the "datapath" on linux doesn't have all files Ovs-prefixed. I don't
>>think there's a specific requirement for datapath-windows for that.
>Sure, we don't have a requirement that the files should be prefixed with
>"Ovs". We just followed a convention - consistently. If you think it
>improves readibility if we don't have Ovs, I don't have any objections to
>> 2. the "datapath" on linux uses a lot of functionality of the linux
>>kernel (such as, the netlink protocol).
>> My belief is that the datapath-windows will, in time, need more things
>>added to it, things that the windows kernel API does not provide for us
>>(one would be, windows netlink protocol), which would inevitably make
>>the file structure more complex.
>Sure, if something is a self-contained entity and outside of the "core"
>OVS logic, it can reside in its own sub-directory. But, there has to be
>such code, first, is my belief. Netlink might be a candidate. If there
>are more than 3-4 files, it is better to put them in a separate
>directory. Similarly for the crypto library we talked about in another
>thread, to complete any IPSec offloads in the future. If it is a
>self-cotained entity outside of the core OVS logic, sure, it can go in
>its own sub-directory.
>dev mailing list
>dev at openvswitch.org

More information about the dev mailing list