need new interface: time-hardware

[Christian Ehrhardt ]

Hi,
since snappy hw-assign isn't existing anymore favoring explicit interfaces I think we need this "group" of HW to get time signals defined as one interface: "time-hardware"

In particular I look at ntp and what devices it "usually" uses.
There are more ancient ones which I intentionally don't add until there is a need for them, but the following list would be IMO the correct one for "hardware that is usually used to fetch time information from" - like pps clocks and use serials with constant blips.

I went into a discussion with the ntpsec developers and came up with this list for this interface. Could

Refclocks via tty or refclock devices:
/dev/ttyS%d+
/dev/ttyUSB%d+
/dev/ttyAMA%d
/dev/refclock-%d+
/dev/refclockpps-%d+

PPS/GPS devices
/dev/pps%d+
/dev/gps%d+
/dev/gpspps%d+
/dev/hpgps%d+

Further Special clock devices:
/dev/acts%d+
/dev/cuaa%d+
/dev/dumbclock%d+
/dev/jjy%d+
/dev/neoclock4x-%d+
/dev/oncore.pps.%d+
/dev/oncore.serial.%d+
/dev/spectracom%d+
/dev/trimble%d+
/dev/zyfer%d+

I know it is a huge list, but those are the devices commonly used as soon as refclocks are involved. OTOH most devices are fairly safe, the only ones that could have something else attaches are the tty* devs - and even those shouldn't be a risk I hope.

The Interface should be safe to auto-connect.

If due to the tty* devices it will not autoconnect I'd ask for two interfaces instead
time-hardware (with everything I listed but ttys and auto-connectes)
tty (/dev/tty* and with manual connect)
Please let me know what you prefer.

[Jamie Strandboge (jdstrand)]

Thanks for the bug report. I think that the 'just clock' devices should probably be handled by the system-time-control interface from bug #1616834. The tty ones would be handled by the existing serial-port interface.

Are you planning on proposing a PR to snapd to implement this?

[Christian Ehrhardt  (paelzer)]

Is the serial-port interface /dev/tty* I'd have thought it has more limitations.
Sometimes I wish I'd get the generated seccomp/apparmor profiles (if there is a way I don't know it yet).

I'm not entirely convinced on "merging" this with the system-time-control interface.
Those devices listed in this bug here are used to get usually signals at high or accurate (preferaby both) frequency. It has nothing to do with actually controlling - like setting - the time.
That is why I filed two bugs intentionally - I'm surely open for discussion, but I really think those are two fully separate interfaces.

As with the other bug I would have tried a PR, but recently I've had a few higher prio things incoming so for now I 'd have to hope and rely on you and the other snapsperts.

[Launchpad Janitor (janitor)]

[Expired for Snappy because there has been no activity for 60 days.]

[Christian Ehrhardt  (paelzer)]

Just because neither of us had time this still is a valid request.
I guess we both forgot to reset from incomplete to new after my last update.