Re: RFC: Serial port DTR/RTS - O_NRESETDEV

["Theodore Ts'o" <tytso@mit.edu>]

On Mon, Nov 10, 2025 at 07:57:22PM -0800, H. Peter Anvin wrote:
> I really think you are looking at this from a very odd point of
> view, and you seem to be very inconsistent. Boot time setup? Isn't
> that what setserial is for? We have the ability to feed this
> configuration already, but you need a file descriptor.

I'm not really fond of adding some new open flag that to me seems
**very** serial / RS-485 specific, and so I'm trying to find some
way to avoid it.

I also think that that the GPIO style timing requirements of RTS
**really** should be done as a line discpline, and not in userspace.

> Honestly, though, I'm far less interested in what 8250-based hardware does than e.g. USB.

I'm quite confident that USB won't have "state" that will be preserved
across a reboot, because the device won't even get powered up until
the USB device is attached.  And part of the problem was that the
requirements weren't particularly clear, and given the insistence that
the "state" be preserved even across reboot, despite the serial port
autoconfiguration, I had assumed you were posting uing the COM 1/2/3/4
ports where autoconfiguration isn't stricty speaking necessary.

In some ways, USB ports might be easier, since it should be possible
to specify udev rules which get passed to the driver when the USB
serial device is inserted, and so *that* can easily be done without
needing a file descriptor.

And for this sort of thing, it seems perfectly fair to hard code some
specific behavior using either a boot command line or a udev rule,
since you seem to be positing that the serial port will be dedicated
to some kind of weird-shit RS-485 bus device, where any time RTS/DTR
gets raised, the bus will malfunction in weird and wondrous ways....

     	     	     	  	      	 - Ted