Re: [meta-oe][PATCH 4/5] gpsd: add optional support for KPPS interface

["Peter A. Bigot" <pab@pabigot.com>]

On 08/28/2014 10:47 AM, Martin Jansa wrote:
> On Thu, Aug 28, 2014 at 10:23:54AM -0500, Peter A. Bigot wrote:
>> On 08/28/2014 09:32 AM, Martin Jansa wrote:
>>> On Thu, Aug 28, 2014 at 08:05:54AM -0500, Peter A. Bigot wrote:
>>>> On 08/28/2014 07:53 AM, Burton, Ross wrote:
>>>>> On 28 August 2014 13:06, Peter A. Bigot <pab@pabigot.com> wrote:
>>>>>> +PACKAGECONFIG ??= ""
>>>>>> +PACKAGECONFIG[kpps] = ",,pps-tools"
>>>>> That's not actually deterministic - if pps-tools is installed but the
>>>>> packageconfig option is disabled then gpsd will still enable the
>>>>> support.
>>>> Yeah, I'm aware of that.  It's also not something that can be
>>>> controlled, since gpsd's author doesn't believe in configuration options
>>>> to enable features: every capability is enabled or disabled by
>>>> inspecting the environment at compile-time.
>>>>
>>>> Although ntp does support some explicit enable/disable flags, it too
>>>> fails to provide a way to say "Pay no attention to that PPS header, it
>>>> isn't really there."
>>> Then we need to patch their configure.
>>>
>>>> For this situation I don't think there's a big issue.  The PACKAGECONFIG
>>>> setting ensures that the header will be available if the feature is
>>>> desired.  If it happens to be present but PPS support isn't explicitly
>>>> requested, there's no failure in either build or runtime: it's still
>>>> gated by runtime checks for PPS sources and the option being enabled in
>>>> the Linux kernel.  (There are no runtime libraries that need to be
>>>> installed to use KPPS.)
>>>>
>>>> Is this going to be a problem with the patch being accepted?
>>> Yes
>>>
>>> people can be used to have KPPS support enabled by "accident" e.g.
>>> because they are building ntp with KPPS support and pps-tools is almost
>>> always built before gpsd..and then once it's built in different order and end-user will be
>>> surprised by lost KPPS support from gpsd.
>> The number of people who will use KPPS is incredibly small, and nobody's
>> going to use it unintentionally as it requires on-target configuration.
>> Those who need it, though, have no recourse other than to build ntpd or
>> gpsd outside of OE if patches like these aren't present.
>>
>> I understand the reasoning and agree in theory that absolute determinism
>> would be ideal, but believe hacking the ntp and gpsd configuration
>> infrastructure to explicitly disable use of a detected PPS header would
>> present a bigger risk and long-term cost to stability and
>> maintainability in OE than the possibility you've identified.  So that
>> solution isn't something I'm going to take on.
>>
>> An alternative is to add kpps to the default PACKAGECONFIG, so the
>> required header is normally available.  The cost of the feature's
>> presence in the packages is nearly zero (a slight increase in daemon
>> code size, and an extra check when the process starts.)  Would that be
>> acceptable?
> More acceptable than the undeterministic behavior - you should even add
> it to DEPENDS.

So not make it configurable at all?

OK, I think that would be safe, and would eliminate the existing 
non-determinism.  I'll rework the patches to do that.

Peter

>> If we can't come to an agreement, then the only patch that's really
>> important is the first one which restores the ability to diagnose
>> misconfigured NTP systems.  Please let me know whether I should mark the
>> others as withdrawn in patchwork.
>