--- /dev/null
+How to Submit Patches for Open vSwitch
+======================================
+
+Send changes to Open vSwitch as patches to discuss@openvswitch.org.
+One patch per email, please. More details are included below.
+
+If you are using Git, then "git format-patch" takes care of most of
+the mechanics described below for you.
+
+Before You Start
+----------------
+
+Before you send patches at all, make sure that each patch makes sense.
+In particular:
+
+ - A given patch should not break anything, even if later
+ patches fix the problems that it causes. The source tree
+ should still build and work after each patch is applied.
+ (This enables "git bisect" to work best.)
+
+ - A patch should make one logical change. Don't make
+ multiple, logically unconnected changes to disparate
+ subsystems in a single patch.
+
+ - A patch that adds or removes user-visible features should
+ also update the appropriate user documentation or manpages.
+
+Testing is also important:
+
+ - A patch that adds or deletes files should be tested with
+ "make distcheck" before submission.
+
+ - A patch that modifies Linux kernel code should be at least
+ build-tested on various Linux kernel versions before
+ submission. I suggest versions 2.6.18, 2.6.27, and whatever
+ the current latest release version is at the time.
+
+ - A patch that modifies the ofproto or vswitchd code should be
+ tested in at least simple cases before submission.
+
+ - A patch that modifies xenserver code should be tested on
+ XenServer before submission.
+
+Email Subject
+-------------
+
+The subject line of your email should be in the following format:
+[PATCH <n>/<m>] <area>: <summary>
+
+ - [PATCH <n>/<m>] indicates that this is the nth of a series
+ of m patches. It helps reviewers to read patches in the
+ correct order. You may omit this prefix if you are sending
+ only one patch.
+
+ - <area>: indicates the area of the Open vSwitch to which the
+ change applies (often the name of a source file or a
+ directory). You may omit it if the change crosses multiple
+ distinct pieces of code.
+
+ - <summary> briefly describes the change.
+
+The subject, minus the [PATCH <n>/<m>] prefix, becomes the first line
+of the commit's change log message.
+
+Description
+-----------
+
+The body of the email should start with a more thorough description of
+the change. This becomes the body of the commit message, following
+the subject. There is no need to duplicate the summary given in the
+subject.
+
+Please limit lines in the description to 79 characters in width.
+
+The description should include:
+
+ - The rationale for the change.
+
+ - Design description and rationale (but this might be better
+ added as code comments).
+
+ - Testing that you performed (or testing that should be done
+ but you could not for whatever reason).
+
+There is no need to describe what the patch actually changed, if the
+reader can see it for himself.
+
+If the patch refers to a commit already in the Open vSwitch
+repository, please include both the commit number and the subject of
+the patch, e.g. 'commit 632d136c "vswitch: Remove restriction on
+datapath names."'.
+
+If you, the person sending the patch, did not write the patch
+yourself, then the very first line of the body should take the form
+"From: <author name> <author email>", followed by a blank line. This
+will automatically cause the named author to be credited with
+authorship in the repository. If others contributed to the patch, but
+are not the main authors, then please credit them as part of the
+description (e.g. "Thanks to Bob J. User for reporting this bug.").
+
+Comments
+--------
+
+If you want to include any comments in your email that should not be
+part of the commit's change log message, put them after the
+description, separated by a line that contains just "---". It may be
+helpful to include a diffstat here for changes that touch multiple
+files.
+
+Patch
+-----
+
+The patch should be in the body of the email following the descrition,
+separated by a blank line.
+
+Patches should be in "diff -up" format. We recommend that you use Git
+to produce your patches, in which case you should use the -M -C
+options to "git diff" (or other Git tools) if your patch renames or
+copies files. Quilt (http://savannah.nongnu.org/projects/quilt) might
+be useful if you do not want to use Git.
+
+Patches should be inline in the email message. Some email clients
+corrupt white space or wrap lines in patches. There are hints on how
+to configure many email clients to avoid this problem at:
+ http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/email-clients.txt
+If you cannot convince your email client not to mangle patches, then
+sending the patch as an attachment is a second choice.
+
+Please follow the style used in the code that you are modifying. The
+CodingStyle file describes the coding style used in most of Open
+vSwitch. Use Linux kernel coding style for Linux kernel code.
+
+Example
+-------
+
+From 632d136c7b108cd3d39a2e64fe6230e23977caf8 Mon Sep 17 00:00:00 2001
+From: Ben Pfaff <blp@nicira.com>
+Date: Mon, 6 Jul 2009 10:17:54 -0700
+Subject: [PATCH] vswitch: Remove restriction on datapath names.
+
+Commit f4b96c92c "vswitch: Disallow bridges named "dpN" or "nl:N"" disabled
+naming bridges "dpN" because the vswitchd code made the bad assumption that
+the bridge's local port has the same name as the bridge, which was not
+true (at the time) for bridges named dpN. Now that assumption has been
+eliminated, so this commit eliminates the restriction too.
+
+This change is also a cleanup in that it eliminates one form of the
+vswitch's dependence on specifics of the dpif implementation.
+---
+ vswitchd/bridge.c | 23 +++++------------------
+ vswitchd/ovs-vswitchd.conf.5.in | 3 +--
+ 2 files changed, 6 insertions(+), 20 deletions(-)
+
+diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c
+index 32647ea..00cffbc 100644
+--- a/vswitchd/bridge.c
++++ b/vswitchd/bridge.c
+@@ -351,32 +351,19 @@ bridge_configure_ssl(void)
+ void
+ bridge_reconfigure(void)
+ {
+- struct svec old_br, new_br, raw_new_br;
++ struct svec old_br, new_br;
+ struct bridge *br, *next;
+ size_t i, j;
+
+ COVERAGE_INC(bridge_reconfigure);
+
+- /* Collect old bridges. */
++ /* Collect old and new bridges. */
+ svec_init(&old_br);
++ svec_init(&new_br);
+ LIST_FOR_EACH (br, struct bridge, node, &all_bridges) {
+ svec_add(&old_br, br->name);
+ }
+-
+- /* Collect new bridges. */
+- svec_init(&raw_new_br);
+- cfg_get_subsections(&raw_new_br, "bridge");
+- svec_init(&new_br);
+- for (i = 0; i < raw_new_br.n; i++) {
+- const char *name = raw_new_br.names[i];
+- if (!strncmp(name, "dp", 2) && isdigit(name[2])) {
+- VLOG_ERR("%s is not a valid bridge name (bridges may not be "
+- "named \"dp\" followed by a digit)", name);
+- } else {
+- svec_add(&new_br, name);
+- }
+- }
+- svec_destroy(&raw_new_br);
++ cfg_get_subsections(&new_br, "bridge");
+
+ /* Get rid of deleted bridges and add new bridges. */
+ svec_sort(&old_br);
+@@ -793,7 +780,7 @@ bridge_create(const char *name)
+ br = xcalloc(1, sizeof *br);
+
+ error = dpif_create(name, &br->dpif);
+- if (error == EEXIST) {
++ if (error == EEXIST || error == EBUSY) {
+ error = dpif_open(name, &br->dpif);
+ if (error) {
+ VLOG_ERR("datapath %s already exists but cannot be opened: %s",
+diff --git a/vswitchd/ovs-vswitchd.conf.5.in b/vswitchd/ovs-vswitchd.conf.5.in
+index 5483ad5..d82a08a 100644
+--- a/vswitchd/ovs-vswitchd.conf.5.in
++++ b/vswitchd/ovs-vswitchd.conf.5.in
+@@ -50,8 +50,7 @@ configure \fBovs\-vswitchd\fR.
+ .SS "Bridge Configuration"
+ A bridge (switch) with a given \fIname\fR is configured by specifying
+ the names of its network devices as values for key
+-\fBbridge.\fIname\fB.port\fR. (The specified \fIname\fR may not begin
+-with \fBdp\fR followed by a digit.)
++\fBbridge.\fIname\fB.port\fR.
+ .PP
+ The names given on \fBbridge.\fIname\fB.port\fR must be the names of
+ existing network devices, except for ``internal ports.'' An internal
+--
+1.6.3.3
+
git://git.onelab.eu / sliver-openvswitch.git / commitdiff