On 2025-11-12 11:39, Greg KH wrote:

Trimming out stuff to get to the real questions:

On Wed, Nov 12, 2025 at 11:12:22AM -0800, H. Peter Anvin wrote:

quoted

Things that I have identified, at least in my opinion:

1. Opening a device for configuration as opposed to data streaming; in the tty case that doesn't just improve the DTR# and RTS# issue but allows setserial, configuring line disciplines and so on.

As I have said, this is application-specific intent, which is why I strongly believe that it needs to be part of the open system call. I furthermore believe that it would have use cases beyond ttys and serial ports, which is why I'm proposing a new open flag as opposed to a sysfs attribute, which actually was my initial approach (yes, I have already prototyped some of this, and as referenced before there is an existing patchset that was never merged.)

I think this is going to be the most difficult.  I don't remember why I
rejected the old submission, but maybe it would have modified the
existing behaviour?  A new open flag "O_DO_NOT_TOUCH_ANYTHING" might be
the simplest?

That was exactly my proposal - see the header of this thread :)

quoted

3. The only way to determine the type of a tty driver is reading and parsing /proc/tty/drivers; that information is exported neither through ioctl nor sysfs. Exporting *that* through sysfs is probably the easiest of all the improvements.

The "type" is interesting.  We keep adding new "types" of serial ports
to the uapi list, and they don't really show up very well to userspace,
as you say.  Adding this export to sysfs is fine with me, but we should
make it a string somehow, and not just a random number like the current
types are listed as, to give people a chance to keep track of this.

So yes, this too should be done.

I meant to add this to the previous email -- the obvious choice (and what is
in my prototype) is to use the same string as is currently exposed in
/proc/tty/drivers.

	-hpa