[Linux-ha-dev] cl_free: Bad magic number in object at ...
lmb at suse.de
Wed Oct 6 06:06:09 MDT 2004
On 2004-10-06T13:19:43, Lars Ellenberg <l.g.e at web.de> wrote:
> I don't see a reason to have
> LOG, MALLOC, STRDUP, FREE #defined in
> every single lib/plugins/HBcomm/*.c file.
> that belongs into _one_ header.
> same for some more code dups between all those .c files.
> this is asking for trouble, once someone touches that code
> (I know, the answer is "patches are being accepted")
Yeah, I did it for the STONITH modules, but I did notice it's the same
everywhere else... But I didn't want to fumble over it ;-)
> and yes it is fine to have a plugin infrastructure that
> _allows_ things to be different. only it does not make so much
> sense (to me) if _every single user_ of it uses it the same way,
> it only introduces additional indirection, hiding this in
> idirect macros, which are not even used everywhere. iirc, this
> was my first impression of that code (I whined about all those
> different memory allocation "strategies").
> Afaics, there is never anything different im/exported than the
> PILPluginImportSet defined in pils.c line 237.
> So maybe explain to me why this is neccessary
> (I just don't see it), or rip it out.
> ( I guess you won't accept patches to this one :-> )
It's a case of abstraction added before it was ever needed.... ;-)
I'd be in favour of not using it at all, but instead just linking
everything with cl_malloc.c and have a consistent memory allocator
between all components.
Right now, passing memory between the different components (from plugins
to cl_ to heartbeat etc) sort of sucks...
Lars Marowsky-Brée <lmb at suse.de>
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX AG - A Novell company
More information about the Linux-HA-Dev