> >(1) It would be trivial to modify xtnpd and ntpd to do the right
> >thing.  Long term, this is the right thing to do.
> 
> Is it trivial enough that you'll implement it and maintain a
> nonstandard API forever?

The point is to get people who maintain the software to encourage the
others to adopt the 'good' API.  You can't do that unless you
implement the good API to begin with.  And if you're going to
implement the good API, what's the point in doing extra work in all
drivers to implement the broken one?


> >I.e., make the long-term solution the 'right' one, and implement the
> >gross short-term fix as a hack.
> 
> The DCD timestamping has to be done in the chipset-level code.  would
> you really have the tty layer catch the TIODCDTIMESTAMP ioctl and
> re-issue the two new ioctls to the chipset level code?

In a nutshell, yes.

The broken API can be implemented as a composition of non-broken-API
elements.  That is, in a good API, there should be the 'functions':

	enable/disable timestamping
	get timestamp

The code which implements TIODCDTIMESTAMP can do:

	"enable timestamping"
		-- if error returned, return it
	"get timestamp"
		-- ignore error indicating no timestamp
		   to return, if such an error could be
		   generated.


getting the timestamp isn't time-critical, is it?  so the extra
function call shouldn't matter at all.  (_making_ the timestamp is,
yes.  but in getting the timestamp, hey, call that extra overhead the
cost of using a broken interface that's supported for compatibility
only.)


If you do it that way, then every driver only has to implement the
'good' interface, and the brokenness implied by the old, broken
interface is very localized.



cgd