On 2025-11-10 20:38, Theodore Ts'o wrote:

On Mon, Nov 10, 2025 at 07:57:22PM -0800, H. Peter Anvin wrote:

quoted

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 don't think it is.  "Opening this device for configuration."

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

No disagreement there -- and so it is. What I want to do is a way to *attach*
that line discipline without poking with the serial port itself.  That's what
I keep trying to get at.

quoted

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

But again, it is very much a configuration property.  You don't know where
your dynamically assigned serial port will end up -- and you *can't*, because
it is a property of the DCE -- what is plugged *into* the device.

Now you have someone writing a terminal program or something like Arduino and
decide to enumerate serial ports (which, as I stated, you can't actually do
right now without opening the devices).  This is why it makes sense for the
open() caller to declare intent; this is similar to how O_NDELAY replaced
callout devices.

It would be lovely if we could do something like
open("/dev/ttyS0/option-string") and so on, but that is well and truly a far
bigger change to the whole driver API.

	-hpa