Message-ID: <17FF5500-54B4-4456-A870-E43E004589F1@zytor.com>
Date: Sun, 09 Nov 2025 21:20:09 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: "Theodore Ts'o" <tytso@....edu>
CC: linux-serial@...r.kernel.org, linux-api@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: RFC: Serial port DTR/RTS - O_NRESETDEV

On November 7, 2025 9:37:43 AM PST, Theodore Ts'o <tytso@....edu> wrote:
>On Thu, Nov 06, 2025 at 11:53:23PM -0800, H. Peter Anvin wrote:
>> 
>> 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?
>
>> 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. 

Powered by blists - more mailing lists