Re: [Gluster-devel] NetBSD autobuild and cmockery2
Harshavardhana wrote: > +1 - lets vote it hard then! Please vote for it: http://review.gluster.com/#/c/8365/ Once that one is merge we can re-enable NetBSD builds voting. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
Justin Clift wrote: > As a thought is this "hours" or "days" or away? As we way in french "Un tiens vaut mieux que deux tu l'auras", which translated into "less now is better than perhaps more later" -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
On Thursday 24 July 2014 07:04:11 Justin Clift wrote: > Surely there's some way we can make this work, such that the optimised > assembler code is only used for cpu's the support it. With non-optimised > C or something used for the others. I'm just working on it. The use of intel's SSE2 extensions were for testing purposes on initial development. It proved to compute encoding and decoding very fast, but I've always had in mind that this should be changed. However I have been more focused on finding bugs and stabilizing the code than changing this. Now I'm working on a pure C solution. I can't predict how it will really perform, but an estimate will be half of the speed of SSE2 (basically because SSE2 uses 128 bits operations and the new implementation will use 64 bits). However this will still be pretty fast. I'll let you know when it's finished. As a thought is this "hours" or "days" or away? Wondering if we should merge the CR Manu mentioned in the meantime, so NetBSD building works... ;) Thoughts? + Justin ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
On Thursday 24 July 2014 12:51:49 Justin Clift wrote: > As a thought is this "hours" or "days" or away? > > Wondering if we should merge the CR Manu mentioned in the meantime, so > NetBSD building works... ;) I expect to have it ready by the beginning of next week. However that patch (http://review.gluster.org/8366) is already merged into master. So any builds on master shouldn't have any problem. If the patch is also needed for 3.6 branch, you can add it. When I send the modification, I'll also undo the effects of this patch to reenable ec on all platforms. Xavi ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
Hi, On Thursday 24 July 2014 07:04:11 Justin Clift wrote: > On 24/07/2014, at 5:05 AM, Emmanuel Dreyfus wrote: > > Harshavardhana wrote: > >>> The change just disable cluster/ec when MMX is not there. If you have > >>> MMX you have cluster/ec. > >> > >> Unsure - there is assembly code which depends on it but really not sure > >> why!> > > I understand this is an optimized computation: > > * Multiplications in a GF(2^8) with modulus 0x11D using XOR's > > > > Optimization are desirable, but relying on a CPU-specific assembly seems > > wrong to me, as it kills portability (what about if you want to run on > > ARM?) > > That's a good point. There is definitely Fedora ARM and other non-x86 > architectures around that we shouldn't be ruling out. > > Surely there's some way we can make this work, such that the optimised > assembler code is only used for cpu's the support it. With non-optimised > C or something used for the others. I'm just working on it. The use of intel's SSE2 extensions were for testing purposes on initial development. It proved to compute encoding and decoding very fast, but I've always had in mind that this should be changed. However I have been more focused on finding bugs and stabilizing the code than changing this. Now I'm working on a pure C solution. I can't predict how it will really perform, but an estimate will be half of the speed of SSE2 (basically because SSE2 uses 128 bits operations and the new implementation will use 64 bits). However this will still be pretty fast. I'll let you know when it's finished. Xavi ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
On Thu, Jul 24, 2014 at 06:28:43AM +0200, Emmanuel Dreyfus wrote: > > http://review.gluster.org/#/c/8340/ > I merged there my changes for cmockery outside of default search path, > Let us see if that pass autobuild. It does so far, and NetBSD build pass the first test cases as it did before (I break on self heald daemon detection, known problem) Please review. -- Emmanuel Dreyfus m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
> > This is The Right Way in my opinion. I think the current implementation > should not have been merged, but I do not track changes close enough to > had the opportunity to cast a -2 code review in time. > > Note that a voting NetBSD build would have catched it. This changes restores > the build, we could re-enable NetBSD autobuild vote one it is merged: > http://review.gluster.org/#/c/8340/ > +1 - lets vote it hard then! -- Religious confuse piety with mere ritual, the virtuous confuse regulation with outcomes ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
On Thu, Jul 24, 2014 at 07:04:11AM +0100, Justin Clift wrote: > Surely there's some way we can make this work, such that the optimised > assembler code is only used for cpu's the support it. With non-optimised > C or something used for the others. This is The Right Way in my opinion. I think the current implementation should not have been merged, but I do not track changes close enough to had the opportunity to cast a -2 code review in time. Note that a voting NetBSD build would have catched it. This changes restores the build, we could re-enable NetBSD autobuild vote one it is merged: http://review.gluster.org/#/c/8340/ -- Emmanuel Dreyfus m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
On 24/07/2014, at 5:05 AM, Emmanuel Dreyfus wrote: > Harshavardhana wrote: > >>> The change just disable cluster/ec when MMX is not there. If you have >>> MMX you have cluster/ec. >> Unsure - there is assembly code which depends on it but really not sure why! > > I understand this is an optimized computation: > * Multiplications in a GF(2^8) with modulus 0x11D using XOR's > > Optimization are desirable, but relying on a CPU-specific assembly seems > wrong to me, as it kills portability (what about if you want to run on > ARM?) That's a good point. There is definitely Fedora ARM and other non-x86 architectures around that we shouldn't be ruling out. Surely there's some way we can make this work, such that the optimised assembler code is only used for cpu's the support it. With non-optimised C or something used for the others. ? + Justin -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
Luis Pabón wrote: > Hi Emmanuel. I have a bug and a fix where cmockery2 was being linked > with all glusterfs applications. Maybe this fixes your issue: > > http://review.gluster.org/#/c/8340/ I merged there my changes for cmockery outside of default search path, Let us see if that pass autobuild. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
Harshavardhana wrote: > > The change just disable cluster/ec when MMX is not there. If you have > > MMX you have cluster/ec. > Unsure - there is assembly code which depends on it but really not sure why! I understand this is an optimized computation: * Multiplications in a GF(2^8) with modulus 0x11D using XOR's Optimization are desirable, but relying on a CPU-specific assembly seems wrong to me, as it kills portability (what about if you want to run on ARM?) -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
Hi Emmanuel. I have a bug and a fix where cmockery2 was being linked with all glusterfs applications. Maybe this fixes your issue: http://review.gluster.org/#/c/8340/ - Luis On 07/23/2014 11:47 AM, Emmanuel Dreyfus wrote: On Wed, Jul 23, 2014 at 01:09:57PM +, Emmanuel Dreyfus wrote: I need help here: that restores the build, but I also had to fiddle with CFLAGS and LIBS, and I am not sure I did it it in the intended way. I am probbaly wrong since now glusterd breaks on startup because of cmockery2: Guard block of 0xbb28e080 size=0 allocated by (null):0 at 0xbb28e070 is corrupt ERROR: logging.c:2077 Failure! It chokes on a FREE (msgstr) that is perfectly valid. The pointer was obtained by vasprintf(), is it possible it fails to ctach allocations through vasprintf() and vonsider the bloc was not allocated? ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
> The change just disable cluster/ec when MMX is not there. If you have > MMX you have cluster/ec. > Unsure - there is assembly code which depends on it but really not sure why! -- Religious confuse piety with mere ritual, the virtuous confuse regulation with outcomes ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
Harshavardhana wrote: > > http://review.gluster.org/8366 > > Dependence on MMX instruction set > > It passes autobuild and alread +1, it should be easy to merge: > > > > Much needed, but i have NetBSD 6.0 still it compiles fine in a VM? > don't you think enabling MMX would be valid here? The change just disable cluster/ec when MMX is not there. If you have MMX you have cluster/ec. Why does cluster/ec depends on MMX, btw? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
On Wed, Jul 23, 2014 at 09:42:07AM -0700, Harshavardhana wrote: > cmockery2 is not dependent on any external libraries - i finished > FreeBSD port yesterday > https://github.com/lpabon/cmockery2/tree/master/packages/FreeBSD. > It must be showing a real bug in logging.c on NetBSD :-) Please explain it to me. I am convinced it just fails to account allocation inside vasprintf() -- Emmanuel Dreyfus m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
> http://review.gluster.org/8366 > Dependence on MMX instruction set > It passes autobuild and alread +1, it should be easy to merge: > Much needed, but i have NetBSD 6.0 still it compiles fine in a VM? don't you think enabling MMX would be valid here? > http://review.gluster.org/8365 > cmockery2 related problems > I will need help on that one. Even if I manage to build, glusterd > nwo crash with what seems to be a wrong unallocated-free detection > We could make it conditional if '--enable-debug' is not enabled, still discussing internally. Luis doesn't think its a good idea. cmockery2 is not dependent on any external libraries - i finished FreeBSD port yesterday https://github.com/lpabon/cmockery2/tree/master/packages/FreeBSD. It must be showing a real bug in logging.c on NetBSD :-) -- Religious confuse piety with mere ritual, the virtuous confuse regulation with outcomes ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
On Wed, Jul 23, 2014 at 04:47:04PM +0100, Justin Clift wrote: > And yeah, you're completely correct. The status of the v3.6 and master > branches at the moment seem to be "broken" for NetBSD, so work needs to > be done by people to get their bits happy again. > > We can enable the voting right now for the NetBSD autobuilds if needed. The problem is that with the changes that were rushed for release-3.6, it is now completely broken. There are two isues: http://review.gluster.org/8366 Dependence on MMX instruction set It passes autobuild and alread +1, it should be easy to merge: http://review.gluster.org/8365 cmockery2 related problems I will need help on that one. Even if I manage to build, glusterd nwo crash with what seems to be a wrong unallocated-free detection -- Emmanuel Dreyfus m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
On Wed, Jul 23, 2014 at 01:09:57PM +, Emmanuel Dreyfus wrote: > I need help here: that restores the build, but I also had to fiddle with > CFLAGS and LIBS, and I am not sure I did it it in the intended way. I am > probbaly wrong since now glusterd breaks on startup because of cmockery2: > Guard block of 0xbb28e080 size=0 allocated by (null):0 at 0xbb28e070 is > corrupt > ERROR: logging.c:2077 Failure! It chokes on a FREE (msgstr) that is perfectly valid. The pointer was obtained by vasprintf(), is it possible it fails to ctach allocations through vasprintf() and vonsider the bloc was not allocated? -- Emmanuel Dreyfus m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
On 23/07/2014, at 2:09 PM, Emmanuel Dreyfus wrote: > I am a bit furstrated by the status of NetBSD autobuilds: failures are > ignored for now, which makes me wonder why I spent time setting it up :-) Sorry about that Manu. :( The NetBSD autobuild has been configured to "not vote" so far, so failures in it don't really affect the PASS/FAIL outcome for a Gerrit CR. Now that v3.6 has been branched, we can enable it so failures cause the Gerrit CR to to be marked as bad. > And ignoring it lets bugs pass through. And yeah, you're completely correct. The status of the v3.6 and master branches at the moment seem to be "broken" for NetBSD, so work needs to be done by people to get their bits happy again. We can enable the voting right now for the NetBSD autobuilds if needed. (I'm not the right person to help with the technical details you need help with in the rest of the email though) Thoughts? ;) + Justin -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
