Regarding this change, I would also consider to change OVSP_NONE to
UINT16_MAX:
-#define OVSP_NONE ((uint16_t) -1)
+#define OVSP_NONE UINT16_MAX
This macro is used everywhere to be assigned to u16 variables, so it
would be more elegant and portable to express 0xFFFF in this way. Here
is a discussion about this:
http://embeddedgurus.com/barr-code/2011/06/is-uint16_t-1-portable-c-code/
Alternatively, we can use UINT_MAX as well, if we want comply even with C89.
On 11/07/12 19:03, Zoltan Kiss wrote:
This is just a small cosmetic change to express what that value means.
Signed-off-by: Zoltan Kiss<zoltan.k...@citrix.com>
---
datapath/datapath.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/datapath/datapath.c b/datapath/datapath.c
index dc2cfad..b2d6d51 100644
--- a/datapath/datapath.c
+++ b/datapath/datapath.c
@@ -779,7 +779,7 @@ static int ovs_packet_cmd_execute(struct sk_buff *skb,
struct genl_info *info)
if (IS_ERR(flow))
goto err_kfree_skb;
- err = ovs_flow_extract(packet, -1,&flow->key,&key_len);
+ err = ovs_flow_extract(packet, OVSP_NONE,&flow->key,&key_len);
if (err)
goto err_flow_put;
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
