On Fri, Apr 16, 2010 at 06:23:16PM +0200, Lars Marowsky-Bree wrote:
> 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).
Of course the library version will be incremented as well,
and new code needs to depend on that.
Still no need to break backwards compatibility.
And, if new code is able to work with old (feature not there)
_and_ new (feature there) library, by disabling
those parts of its functionality that require the feature,
...
yeah. but you know all that.
> Code just getting an IPC_Channel pointer has no way of figuring out
> which type they've been passed, unless I'm duly mistaken.
Sure. Using the library version.
But if they'd care, they should have requested the "uds_c" anyways.
> That's an additional point: if you keep the soname frozen, one has to
I won't, I never proposed to, so quit bitching about it ;-)
> 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. ;-)
I'm not complicating code.
I even thought I'd simplify it, though that may be a matter of taste.
For me as a programmer, I'd really rather try to use a feature,
have that fail cleanly, and go to my fallback code,
than to ask the library version, check my table of features
supported with some version, and have each use of the feature
embraced with if()s.
For this special case,
ch = ipc_wait_conn_constructor(IPC_UDS_CREAD, whatever)
if (!ch)
well, try again with IPC_ANYTYPE,
and don't use farside_uid.
I admit it is not a big difference compared against
get library version, check my table of features supported, ...
but I'd rather do it this way.
I'm just Vetoing an unnecessary backwards incompatible ABI breakage.
If someone rather hard require libclplumbing == 2.1.0, he may do so.
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
