On Aug 20, 2008, at 11:41 PM, Joel Becker wrote:
> On Wed, Aug 20, 2008 at 11:17:18AM -0700, Steven Dake wrote:
>> On Wed, 2008-08-20 at 18:52 +0200, Andrew Beekhof wrote:
>> We talked on irc and came to the conclusion that apparently it is
>> impossible to fix the kernel issue with the assumptio
On Wed, Aug 20, 2008 at 02:54:04PM -0700, Steven Dake wrote:
> On Wed, 2008-08-20 at 14:41 -0700, Joel Becker wrote:
> > On Wed, Aug 20, 2008 at 11:17:18AM -0700, Steven Dake wrote:
> > > On Wed, 2008-08-20 at 18:52 +0200, Andrew Beekhof wrote:
> > > We talked on irc and came to the conclusion that
On Wed, 2008-08-20 at 14:41 -0700, Joel Becker wrote:
> On Wed, Aug 20, 2008 at 11:17:18AM -0700, Steven Dake wrote:
> > On Wed, 2008-08-20 at 18:52 +0200, Andrew Beekhof wrote:
> > We talked on irc and came to the conclusion that apparently it is
> > impossible to fix the kernel issue with the ass
On Wed, Aug 20, 2008 at 11:17:18AM -0700, Steven Dake wrote:
> On Wed, 2008-08-20 at 18:52 +0200, Andrew Beekhof wrote:
> We talked on irc and came to the conclusion that apparently it is
> impossible to fix the kernel issue with the assumption of 1^31 bits and
> it is impossible to fix the openais
config.h should be included after objdb.h. Patch attached to fix.
Index: services/openaisparser.c
===
--- services/openaisparser.c (revision 1638)
+++ services/openaisparser.c (working copy)
@@ -45,9 +45,9 @@
#include
#include
On Wed, 2008-08-20 at 18:52 +0200, Andrew Beekhof wrote:
> On Aug 20, 2008, at 5:25 PM, Steven Dake wrote:
>
> > This breaks binary compatibility within the protocol.
>
> I can't imagine how...
> It introduces the possibility of duplicates but how is it any
> different to the admin manually sp
On Wed, 2008-08-20 at 18:52 +0200, Andrew Beekhof wrote:
> On Aug 20, 2008, at 5:25 PM, Steven Dake wrote:
>
> > This breaks binary compatibility within the protocol.
>
> I can't imagine how...
The nodeid is sent in the totem headers. If it is mangled on one node
and not another node, then bina
On Aug 20, 2008, at 5:25 PM, Steven Dake wrote:
> This breaks binary compatibility within the protocol.
I can't imagine how...
It introduces the possibility of duplicates but how is it any
different to the admin manually specifying the alternative value?
Also, the admin can still manually ask
On Wed, Aug 20, 2008 at 08:25:55AM -0700, Steven Dake wrote:
> This breaks binary compatibility within the protocol.
We only need to do the negative to positive conversion on values that are
passed out through the API's, e.g. libcpg. corosync/openais can continue
to use the nodeid's as they are.
This breaks binary compatibility within the protocol.
It is also completely unsavory to me.
Finally what is the advantage of converting negative nodeids to positive
ones?
I really think the likelyhood of this patch ever being accepted is
pretty close to zero :)
Regards,
-steve
On Wed, 2008-08-
I'm sure this will be an unpopular patch, however there are good
reasons for it.
Although OpenAIS uses uint32_t for node ids, both the in-kernel and
userspace pieces of the DLM use int32_t.
I'm also told that the chances of the kernel pieces changing approach
zero.
So because the kernel is
11 matches
Mail list logo
