CLOCK_MONOTONIC change reverted [LWN.net]

CLOCK_MONOTONIC change reverted

Posted Apr 26, 2018 13:02 UTC (Thu) by tglx (subscriber, #31301)
In reply to: CLOCK_MONOTONIC change reverted by judas_iscariote
Parent article: CLOCK_MONOTONIC change reverted

Well, even if we file a bug and stuff eventually gets fixed, the change will break existing user space and probably more than just systemd and network mangler. It was expected and it might have been possible to fix this ahead of time, but the only option 4 weeks before the final 4.17 release is to revert it.

to post comments

CLOCK_MONOTONIC change reverted

Posted Apr 27, 2018 14:48 UTC (Fri) by eternaleye (guest, #67051) [Link]

To be honest, what confused me most here was the approach taken to making the change. If a behavior is as useful and widely-documented as CLOCK_BOOTTIME vs. CLOCK_MONOTONIC is (and believe me, the _behavior_ distinction is very useful regardless of name), why was doing a straight renaming in one shot _ever_ considered?

When a behavior's name is suboptimal, there's a pretty well established way of fixing that - introduce a new name, deprecate the old name, and have a deprecation cycle.

1. Add CLOCK_MONOTONIC_ACTIVE as an alias for CLOCK_MONOTONIC, deprecating CLOCK_MONOTONIC (maybe add #warning)
2. Add an #ifdef that people can set to switch (deprecated) CLOCK_MONOTONIC = CLOCK_MONOTONIC_ACTIVE to (new) CLOCK_MONOTONIC = CLOCK_BOOTTIME
3. Flip the default ifdef, after waiting long enough
4. Deprecate CLOCK_BOOTTIME (maybe add #warning)
5. Remove CLOCK_BOOTTIME, after waiting long enough
6. Remove the #ifdef, after waiting long enough (this is last because previous stages _introduce_ errors or at least warnings, while this would cause build-silent misbehavior, as was seen with the current patch)

I cannot think of a reason that "just change it" was considered viable for public, documented API and ABI?