Thanks, I've merged this series.
Ethan
On Mon, Feb 27, 2012 at 15:14, Ben Pfaff wrote:
> On Mon, Feb 20, 2012 at 11:42:15PM -0800, Ethan Jackson wrote:
>> Here's an incremental.
>
> Looks good, thank you.
___
dev mailing list
dev@openvswitch.org
http:/
On Mon, Feb 20, 2012 at 11:42:15PM -0800, Ethan Jackson wrote:
> Here's an incremental.
Looks good, thank you.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Here's an incremental.
---
lib/unixctl.c | 76 +--
lib/vlog.c |2 +-
utilities/ovs-appctl.c |3 +-
3 files changed, 36 insertions(+), 45 deletions(-)
diff --git a/lib/unixctl.c b/lib/unixctl.c
index c68b059..054ce49 10064
> I was suggesting an optional simplification. Obviously when I wrote
> the existing code I had the idea of back-to-back requests in mind, or
> I wouldn't have written it that way. But the only existing client
> only sends a single request per program execution, so multiple
> back-to-back request
On Mon, Feb 27, 2012 at 02:52:37PM -0800, Ethan Jackson wrote:
> > I don't think you need to kill the connection object immediately.
> > Errors are "sticky", that is, the next call to jsonrpc_get_status()
> > will report the same error, so you can let run_connection() in the
> > call to unixctl_ser
On Mon, Feb 27, 2012 at 02:04:54PM -0800, Ethan Jackson wrote:
> > I would argue that run_connection() should only read a new request
> > if the connection is not backlogged (this is already tested in
> > unixctl_server_wait() so maybe that was your intention all along?).
> >
> > I don't think that
> I don't think you need to kill the connection object immediately.
> Errors are "sticky", that is, the next call to jsonrpc_get_status()
> will report the same error, so you can let run_connection() in the
> call to unixctl_server_run() destroy the connection object.
Yeah you're right, I realized
On Mon, Feb 27, 2012 at 01:35:04PM -0800, Ethan Jackson wrote:
> > My thinking was that once I've sent the request, I need to destroy the
> > 'conn' object. and now the caller has this dangling reference.
> > However, the more I think about it, the less valid this argument is
> > because I already
> I would argue that run_connection() should only read a new request
> if the connection is not backlogged (this is already tested in
> unixctl_server_wait() so maybe that was your intention all along?).
>
> I don't think that run_connection() really needs a loop. One try
> should be enough. (I t
> My thinking was that once I've sent the request, I need to destroy the
> 'conn' object. and now the caller has this dangling reference.
> However, the more I think about it, the less valid this argument is
> because I already make assertions preventing a caller from making a
> reply twice. Perha
> In enable_slave() in lib/bond.c, I think that the following is
> actually a bug fix. If so, can you separate out the bug fix from the
> wholesale conversion, so that we can commit it to old release
> branches?
>
> bond_enable_slave(slave, enable, &bond->unixctl_tags);
> - unixctl_command
On Thu, Feb 16, 2012 at 04:57:17PM -0800, Ethan Jackson wrote:
> The unixctl library had used the vde2 management protocol since the
> early days of Open vSwitch. As Open vSwitch has matured, several
> Python daemons have been added to the code base which would benefit
> from a unixctl implementat
12 matches
Mail list logo
