On Tue, 2009-09-08 at 22:30 -0700, Steven Dake wrote: > On Wed, 2009-09-09 at 07:22 +0200, Fabio M. Di Nitto wrote: > > I am not objecting for the idea of small-memory-footprint but I do have > > a few questions: > > > > Why are those values hardcoded in the first place? > > > > Wouldn't be a better long term investment to have them configurable? > > > > (Not having investigated what all does values mean) > > > > What happens if one normal corosync build is executed on machine A and a > > small-memory on machine B? Will they be able to work properly together > > or can we expect issues because B might have a performance hit? > > > > +#define MESSAGE_SIZE_MAX 1024*64 > > > > What if node A is sending a bigger message to node B? wouldn't that > > break on-wire compatibility for applications? > > > > Yes it would, but i'm ok with breaking onwire compat in the case where > the builder explicitly requests something special for their small > footprint design (hence no backward compatibility requirements).
Ok can we revive 2 seconds the idea to add a string to the corosync exec that explicitly mention what features are built into the binary/package? I think I suggested it a long time ago but never got around to do it. Something that can tell us if there is nss/small-memory/whatever feature built in that is not selectable at runtime. It's a matter of a 2/3 lines change in configure.ac and a log_printf( in the main exec and can spare us the trouble to figure out that 2 builds are incompatible (if users doesn't know what binary packages he received from whatever distro and they are not compatible between them). Fabio _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
