On November 7, 2025 9:37:43 AM PST, Theodore Ts'o [off-list ref] wrote:

On Thu, Nov 06, 2025 at 11:53:23PM -0800, H. Peter Anvin wrote:

quoted

I recently ran into a pretty serious issue due to the Unix/Linux
(mis)behavior of forcing DTR and RTS asserted when a serial port is
set, losing the pre-existing status in the process.

There's a hidden assumption in your problem statement which is that
DTR / RTS has a "state" which can be saved when the serial port is not
active, where active is one or more file descriptors holding the
serial port open.  There may be certain hardware or drivers where this
is just not possible, because nothing is defined if the serial port is
not active.  It might make sense if you are using a 8250 UART, but not
all the world is the National Semiconductor (or clones) UART.

Certainly the "state" will not be preserved across boots, since how we
autodetect the UART is going to mess with UART settings.  So
*presumably* what you are talking about is you want to be able to open
the serial port, mess with DTR / RTS, and then be able to close the
serial port, and then later on, re-open the serial port, have the DTR
/ RTS remain the same.  And it's Too Hard(tm) to have userspace
keeping a file descriptor open during the whole time?  (Which is
traditionally how Unix/Linux has required that applications do
things.)

Is that a fair summary of the requirements?

quoted

It seems to me that this may very well be a problem beyond ttys, in
which case a new open flag to request to a driver that the
configuration and (observable) state of the underlying hardware
device -- whatever it may be -- should not be disturbed by calling
open(). This is of course already the case for many devices, not to
mention block and non-devices, in which case this flag is a don't
care.

I think it's going to be a lot simpler to keep this specific to serial
ports and DTR / RTS, because the concept that the hardware should not
be changed when the file descriptor is opened may simply not be
possible.  For example, it might be that until you open it, the there
might not even be power applied to the device.  The concept that all
hardware should burn battery power once the machine is booted may not
make sense, and the assumption that hardware has the extra
millicent(s) worth of silicon to maintain state when power is dropped
may again, not be something that we can assume as being possible for
all devices.

If that's the case, if you want to have something where DTR and RTS
stay the same, and for some reason we can't assume that userspace
can't just keep a process holding the tty device open, my suggestion is to use 

Given that DTR and RTS are secial port concepts, my suggesiton is to
set a serial port flag, using setserial(8).  It may be the case that
for certain types of serial device, the attempt to set the flag may be
rejected, but that's something which the ioctl used by setserial
already can do and which userspace applications such as setserial
understand may be the case.

Cheers,

					- Ted

So let's separate out a few things here:

1. You are taking about using setserial(8), which is really ioctl(TIOCSSERIAL), which requires a file descriptor. This is exactly why I believe there should be a mechanism for acquiring a file descriptor which *by that action itself* should not change whatever state is already available to the kernel.

2. What, if anything, can be done on a device by device basis to improve the situation beyond what currently exists.