Re: RFC: Serial port DTR/RTS - O_NRESETDEV

["H. Peter Anvin" <hpa@zytor.com>]

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:
>> 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 :)

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