Bill  Studenmund writes:

>1) The driver handles the compatability ioctl itself

1) That's what I've done for now.

Anything else really want an upcall or a a continuation to get back
into the driver routine. There're several ways to kludge that but they
are all kludges.

If tty devices were the only place we wanted DCD timestamping, and if
it was really an attribute of the tty, then I'd go for putting it into
the tty layer.  But it isn't really a tty attribute: it's a hardware
frob to get a pulse-per second signal.

I could easily see how someone could want to wire up the DCD signal
on, say, a zs port connected to a secondary keyboard. AFAIK the kbd on
a zs won't get a tty struct.

And we should really do this for parallel ports too, so it'd be
duplicated there regardless.

Besides, the ``other'' timekeeping frob (the obsolete CHU clocks) want
a timestamp on every received data char; and that really does have to
be handled in the chipset-driver layer.

>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.

cgd says (1) is a reasonable implementation choice given how the code
is currently structured.  So, how about we go with (1) and defer
moving DCD timestamps and clock disciplinse to the tty layer (i.e.,
setting the precedent) until after the new wscons code has settled
down, and we have more experience with how it'll be used?