On 6 May 2026, at 0:52, Ilya Maximets wrote:
> Windows support was deprecated in 3.7, it's time to remove it.
>
> We already removed the installer and the datapath implementation.
> Now removing all the code related to talking to the Windows datapath,
> building on Windows, using MSVC as a compiler, and the final bits of
> documentation related to Windows-specific behavior of certain features.
>
> It is possible to split this change into smaller parts, but it will
> be a non-trivial amount of work to keep the patches in a working state
> in the process. So, just removing everything at once. It would also
> be easier to re-apply in case someone wants to resurrect this code or
> maintain the Windows support in their own fork.
>
> A couple mentions of MSVC quirks are left in public headers as the
> code is good enough and there is no real need to change the way it
> is written at the moment.
>
> Signed-off-by: Ilya Maximets <[email protected]>
This took some time to review, so it was probably also hard to make all these
changes ;)
See some comments inline, but also some general ones here:
- faq/contributing.rst still has the below paragraph:
The Windows datapath kernel module support, on the other hand, is
maintained within the OVS tree, so patches for that can go directly to
ovs-dev.
- /faq/general.rst still has the following Windows reference:
We've seen
Open vSwitch ported to a number of different platforms, including FreeBSD,
Windows, and even non-POSIX embedded systems.
- The below comments still reference to windows, but I guess it should be fine:
- vswitchd/bridge.c:2125; "only necessary on Windows"
- include/openvswitch/util.h:146,285; MSVC variadic/init macro comments
- include/openvswitch/ofp-errors.h:44; "and Windows"
- lib/timeval.c:775; Visual Studio 2013 crash comment
//Eelco
[...]
> diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
> index f22a87934..65a9c3be5 100644
> --- a/lib/dpif-netlink.c
> +++ b/lib/dpif-netlink.c
[...]
> @@ -3555,8 +3249,6 @@ dpif_netlink_ct_timeout_policy_dump_done(struct dpif
> *dpif OVS_UNUSED,
> free(dump_state);
> return err;
> }
> -#endif
> -
The diff does not show it, but we should keep one additional
newline after the FF.
[...]
> diff --git a/lib/lockfile.c b/lib/lockfile.c
> index 42782d29e..6ecbb307e 100644
> --- a/lib/lockfile.c
> +++ b/lib/lockfile.c
In the struct below, there is still 'HANDLE lock_handle', should this be
removed?
struct lockfile {
struct hmap_node hmap_node;
char *name;
dev_t device;
ino_t inode;
int fd;
HANDLE lock_handle;
};
[...]
> diff --git a/lib/poll-loop.c b/lib/poll-loop.c
> index 70fabeb8a..cbeb6990b 100644
> --- a/lib/poll-loop.c
> +++ b/lib/poll-loop.c
The below structure and some of the other code in poll-loop.c still have
'wevent' references, I guess they all need to be removed.
struct poll_node {
struct hmap_node hmap_node;
struct pollfd pollfd; /* Events to pass to time_poll(). */
HANDLE wevent; /* Events for WaitForMultipleObjects(). */
const char *where; /* Where poll_node was created. */
};
[...]
> diff --git a/ovsdb/log.c b/ovsdb/log.c
> index 86d6bdc24..6d75427cf 100644
> --- a/ovsdb/log.c
> +++ b/ovsdb/log.c
>
[...]
> @@ -882,20 +822,12 @@ void
> ovsdb_log_replace_abort(struct ovsdb_log *new)
> {
> if (new) {
> - /* Unlink the new file, but only after we close it (because Windows
> - * does not allow removing an open file). */
> - char *name = xstrdup(new->name);
> + /* Unlink and close the new file. */
> + unlink(new->name);
> ovsdb_log_close(new);
> - unlink(name);
> - free(name);
> }
> }
>
> -void
> -ovsdb_log_disable_renaming_open_files(void)
This function's declaration still exists in ./ovsdb/log.h.
> -{
> - rename_open_files = false;
> -}
>
[...]
> diff --git a/utilities/checkpatch.py b/utilities/checkpatch.py
> index 9a10b78a9..2f7123586 100755
> --- a/utilities/checkpatch.py
> +++ b/utilities/checkpatch.py
> @@ -1059,7 +1059,7 @@ def ovs_checkpatch_parse(text, filename, author=None,
> committer=None):
> continue
>
> # Skip files which have /datapath in them, since they are
> - # linux or windows coding standards
> + # linux coding standards
Should we add a dot (.) while we are at it?
> if current_file.startswith('datapath'):
> continue
> if current_file.startswith('include/linux'):
[...]
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
