OK for the content change

Incorporate recommendation of highlighting why we want to deprecate it.

Replaced with separated imports/build bits.

Strip "All rights reserved" at Anderw's request, upgrade dmb -> dsb.

Address review feedback

Sorry, crap description that won't be used as-is. libecc and libder will be used for forthcoming ECC support in pkg(7).

Update following better tracking of our cloners, add a basic test as well

Ping

Return ENXIO for tty_gone in uart_command_barrier to match uart_command_queue,
convert it to ENODEV in the ioctl layer to match ttyil_ioctl.

Override cv_wait_sig() errors if neither of the tasks are currently enqueued,
because the caller doesn't actually care beyond that..

Return ENXIO from ucom_queue_command; the ENOTTY conversion to ENXIO in some
callers goes away for now.

This has been split into:

In D24459#1092986, @kib wrote:

In D24459#1092727, @kevans wrote:

Actually, it looks like our driver callbacks typically do timeouts when they actually submit to the controller: https://cgit.freebsd.org/src/tree/sys/dev/usb/serial/uftdi.c#n1688 -- so most of these should be reasonably bounded. Perhaps still good to be defensive, since I'm not about to audit every path out of usb_serial.c

I believe this is palliative. If you want to hold the lock around driver calls, then _tty_lock should do sx_sig_lock() and propagate the locking error back.

Actually, it looks like our driver callbacks typically do timeouts when they actually submit to the controller: https://cgit.freebsd.org/src/tree/sys/dev/usb/serial/uftdi.c#n1688 -- so most of these should be reasonably bounded.

In D24459#1092725, @kib wrote:

In D24459#1092724, @kevans wrote:

In D24459#1092714, @kib wrote:

So userspace might end up waiting uninterruptibly for hw to finish something?

Yes, though we could presumably implement usb_proc_mwait_sig() for an escape hatch. It would be an improvement even before this change, because open/close will both drop the tty lock and wait potentially uninterruptibly for the hardware.

Well, this might help with the driver thread itself, but what about user threads that happen to wait for the same sx? Your _tty_lock() is uninterruptible. This would cause lock cascade, and user needs to know which thread to kill to unblock the dependency chain.

In D24459#1092714, @kib wrote:

So userspace might end up waiting uninterruptibly for hw to finish something?

In D24459#1092380, @imp wrote:

This looks good from 10k feet, but I've not thought it all through.
I suspect this review is getting close to too long to easily review and some subsetting (like the tty_assert_locked -> ttydisc_assert_locked) might be helpful.
I'll look in more detail later, so far just one question, but it seems kinda basic to my understanding of the rest.

Heh, whoops-

Resurrect the tty lock split patch from the dead; better describe the sleeps we're wanting to enable -- the general idea is that anything coming in via the tty layer to a driver should sleep as needed so that we can meet thet usual termios promise that when, e.g., tcsetattr() returns, the change has actually taken effect. This is often important so that userland applications trying to configure a tty can get relative timing correct if there's some minimum requirement between operations they're doing.