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 specifying the alternative value? > Also, the admin can still manually ask for numbers beyond the positive > range of a signed integer and this code will not touch it. > > > It is also completely unsavory to me. > > > > Finally what is the advantage of converting negative nodeids to > > positive > > ones? > > Did you read any of what I wrote besides the patch? > > > I really think the likelyhood of this patch ever being accepted is > > pretty close to zero :) > > I knew that before submitting. > But I still felt obliged to do so. > > Sorry for wasting your time. > > > > > > > Regards, > > -steve > > > > On Wed, 2008-08-20 at 10:10 +0200, Andrew Beekhof wrote: > >> 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 using signed ints, other pieces of the > >> RedHat > >> stack also use signed ints, clusters are unlikely to span the entire > >> ipv4 address space (thus making dups unlikely) and that nodeids can > >> be > >> manually assigned even if a dup occurs... I propose the following > >> patch that converts any negative nodeid back into a positive one. > >> > >> http://hg.clusterlabs.org/extra/openais/whitetank/raw-rev/ > >> b6a7886a3e90 > >> > >> diff -r 70c18fd72ea9 -r b6a7886a3e90 exec/totemnet.c > >> --- a/exec/totemnet.c Thu Aug 14 07:31:36 2008 +0200 > >> +++ b/exec/totemnet.c Mon Aug 18 12:17:10 2008 +0200 > >> @@ -702,7 +702,12 @@ static int netif_determine ( > >> * field is only 32 bits. > >> */ > >> if (bound_to->family == AF_INET && bound_to->nodeid == 0) { > >> - memcpy (&bound_to->nodeid, bound_to->addr, sizeof (int)); > >> + int nodeid = 0; > >> + memcpy (&nodeid, bound_to->addr, sizeof (int)); > >> + if(nodeid < 0) { > >> + nodeid = 0 - nodeid; > >> + } > >> + bound_to->nodeid = nodeid; > >> } > >> > >> return (res); > >> > >> _______________________________________________ > >> Openais mailing list > >> [email protected] > >> https://lists.linux-foundation.org/mailman/listinfo/openais > > >
Ok, 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/corosync assumption of 1^32 bits nodeids. Therefore a patch (with man page) of an api that gets the nodeids in 31 bit fashion from cpg would be workable. ie: cpg_nodid_31bit_set(handle). would be suitable if this would meet everyone's needs. Regards -steve _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
