On Mon, 20 Apr 1998, Jonathan Stone wrote:

> 
> I think this addresses all the points so far. Three new ioctls:
>   * one to set DCD timestamping on or off
>   * one to get DCD timestamping on/off state
>   * one to just fetch the most-recent timestamp.
>     silently returns zero if timestamping is not enabled.
>     should this return an error instead?
> 
> Better names for the ioctls welcomed: i'm lousy at thinking up names.
> Aside from that (and typos) same conditions as the last patch.

Looks ok. My only suggestion is to move most of it to the tty layer.
Getting the state of timestamping, and getting the current timestamp will
be common functions for all the drivers. The only thing the driver really
needs to do itself is the on/off ioctl.

Since the tty structure is bzeroed on initialization, things are fine.

One problem with this idea is the compatability ioctl. It either would
need to be handled in the driver, or the tty layer would have to let the
tty layer do part of the process.

1) The driver handles the compatability ioctl itself

2) For the compatability ioctl, the tty layer calls the driver's ioctl
routine to turn on timestamping, returning an error if no timestamping
available

3) We add a new ttyioctl error message, EPARTLY_DONE or some better name.
It means that the tty layer did something, but the driver's ioctl
routine needs to do something too. The tty layer sets up the return value,
and then the driver processes the ioctl in its switch statement. A driver
w/o timestamping will return ENOTTY, so the return value won't matter. A
driver which can timestamp will just set the timestamping enable flag. The
return timestamp will already be set up fine.

Option 3 does the least work, and probably is the most efficient. Though
there's no precedent for an ioctl being served by both the tty-layer ioctl
servicer and the driver's ioctl routine. Option 3 has one less subroutine
call than #2. Option 1 results in code duplication, but might be the most
easily maintained option.

Take care,

Bill