On 2010-04-16T13:48:17, Lars Ellenberg <[email protected]> wrote:
> Old code works with old and new glue.
> New code works with old and new glue.
>
> New code depending on the new struct members get a define to check for
> at compile time, and a runtime check just as well.
>
> New code depending on the new struct members SHOULD request IPC_UDS_CRED
> instead of IPC_DOMAIN_SOCKET or IPC_ANYTYPE, even though with new glue
> they get the same struct back.
>
> This is so they will notice cleanly when they accidentally are running
> against old glue, and not notice by segfaulting uncontrollably somewhen
> later.
>
> This is still all hackish, but should work well enough.
>
> Makes sense so far?
No. This hackish (your own word) where a simple soname++ would solve it
cleanly. It complicates the usage, and proper new code is stuck with the
hack forever (until we one day dare to increase the soname and can drop
it again).
The runtime check is implicit, of course, since the old code will simply
fail if the app requests the new socket type. Code will have to be added
to meaningfully deal with this.
We'll be getting weird bugs where the app intended to request with
credentials but ended up accidentially requesting the wrong type, which
will - depending on memory alignment/padding - sometimes segfault,
sometimes not.
Code just getting an IPC_Channel pointer has no way of figuring out
which type they've been passed, unless I'm duly mistaken.
You didn't reply to my point regarding this: for a libglue1 /
custer-glue upgrade to take effect, one has to restart the cluster stack
anyway on the node. (To restart lrmd and make everyone use the new
libglue1 version.) There's no additional downtime associated with
upgrading pacemaker et al as well.
The dependencies are all taken care of by the various build systems and
installers as well.
That's an additional point: if you keep the soname frozen, one has to
add explicit version dependencies to the packages that require this
functionality, which again is additional overhead - soname is tracked by
the package managers automatically.
Frankly, I don't get why we should bother to complicate the code in
_any_ fashion to keep this ABI compatible. I'm not the official
maintainer, of course, but if I was, I'd be waving a "veto" flag over my
head. ;-)
ABIs that are "semi-compatible" are more annoying to deal with than
those that break stuff cleanly. It's not as if customers would run into
this by accident - their package manager will tell them that the soname
doesn't match and they need to upgrade the rest too.
And I do believe I have got some experience with packaging HA stuff.
Regards,
Lars
--
Architect Storage/HA, OPS Engineering, Novell, Inc.
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
