fallenpega...@gmail.com said:
> My inclination is that when more clock types show up, they get a driver
> running in it's own process space, and exporting a SHM buffer.
We should clean up the SHM interface first. The ntpd side should be read
only.
> The problem with covering existing drivers t
My inclination is that when more clock types show up, they get a driver
running in it's own process space, and exporting a SHM buffer.
The problem with covering existing drivers to that is... testing them.
..m
On Sun, Jan 29, 2017 at 10:49 PM Eric S. Raymond wrote:
> Hal Murray :
> > It's not
Hal Murray :
> It's not clear that there is any good way to have a starting point reference.
> If you give examples of all the possibilities, it will be too complicated.
> You can start with an existing driver. That's easy if you already know your
> way around, but there is likely to be a lot
fallenpega...@gmail.com said:
> Is there a reason to keep dumbclock? Maybe it exists as a starting
> framework for when someone wants to write a new clockdriver?
It's not good for much more.
It's not clear that there is any good way to have a starting point reference.
If you give examples o
Mark Atwood :
> Kill it
Will do.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Kill it
On Sun, Jan 29, 2017 at 9:05 PM Eric S. Raymond wrote:
> Mark Atwood :
> > Is there a reason to keep dumbclock? Maybe it exists as a starting
> > framework for when someone wants to write a new clockdriver?
>
> Actually, I only left dumbclock in because you said "keep it for the lulz"
Mark Atwood :
> Is there a reason to keep dumbclock? Maybe it exists as a starting
> framework for when someone wants to write a new clockdriver?
Actually, I only left dumbclock in because you said "keep it for the lulz"
during the conversation about some other refclock that we ended up dropping
Is there a reason to keep dumbclock? Maybe it exists as a starting
framework for when someone wants to write a new clockdriver?
..m
On Sun, Jan 29, 2017 at 5:36 AM Eric S. Raymond wrote:
> Here are the full current stats:
>
> all71320 (100.00%) in 298 files
> c 60694
Here are the full current stats:
all71320 (100.00%) in 298 files
c 60694 (85.10%) in 152 files
python 7472 (10.48%) in 48 files
shell 1444 (2.02%) in 7 files
yacc1255 (1.76%) in 1 files
waf 455 (0.64%) in 11 files
We're down to
