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

It's taken a decade for Unix vendors to support this *at all*.
Given that, i'm not at all interested in a battle to do it more cleanly.


But if you guys insist on an ideologically-pure API, fine.  The
question is how we implement the existing API which the thirdparty
source _does_ use.

>implement the good API, what's the point in doing extra work in all
>drivers to implement the broken one?

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.

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.

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.