> But if you guys insist on an ideologically-pure API, fine.

I think "we do," though obviously i cannot speak for Jason.


> The
> question is how we implement the existing API which the thirdparty
> source _does_ use.
>
> The "broken" ioctl which does both "enable" and "sample" is four lines
> of code in each driver (currently two: com.c and ZS), not counting the
> softc machinery which has to go in either way.


In general, if you have to implement brokenness, then do it in a way
that involves the least code/effort over the long term.

4 lines in com, 4 lines in zs, 4 lines in scn, 4 lines in any other
serial driver in which you might want to implement the support (and
there others where you might want to implement it; those drivers were
the first three that came to mind).


> I looked at doing this in another context.  the best way I thought of
> so far for an "MI", ldisc-independent ioctl is to drop code into
> ttioctl() which pulls tp->t_dev, and then calls the cdevsw ioctl entrypoint.

Which admittedly is ugly (recursive call into the device's ioctl
entrypoint... not a great idea).


> Maybe there's a better way. But I thought handling the old ioctl API
> inline in the chipset-level code "while we're in there" was a cleaner option.

Looking at the code, that may in fact be true.  (Even so, you still
have to implement the 'good' bits.)

I actually wonder if a more general facility is in order and/or
useful, e.g. allowing timestamping to be enabled on one of:

	(1) "DCD events"

	(2) "character interrupts"

	(3) (other events which I can't think of right now),

etc., in which case it might be best to put the timestamps and some of
the generic ioctl handling (but not the timestamping) into 'struct
tty'.


Looking at the existing implementation choices:

(1) if you want to implement the broken interface, you get to
implement the non-broken one as well.

(2) if you want to implement it all in the low-level drivers, that's
not unreasonable given the existing structure of the code.



cgd