linux-kernel - Re: RFC: Serial port DTR/RTS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <14b1bc5c-83ac-431f-a53b-14872024b969@zytor.com>
Date: Thu, 13 Nov 2025 14:24:27 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: "Theodore Ts'o" <tytso@....edu>, Maarten Brock <Maarten.Brock@...ls.nl>,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: RFC: Serial port DTR/RTS - O_<something>

On 2025-11-12 11:39, Greg KH wrote:
>>
>> 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?
> 

Okay, to I'm going to toss out a couple suggestions for naming:

	O_(PRE|FOR|N|NO)?(INIT|CONFIG|START)(DEV|HW|IO)?
	O_(NO?RESET|PREPARE)(DEV|HW|IO)?
	O_NO?TOUCH
	O_NYET ("not yet")

I think my personal preference at the moment is either O_NYET or O_PRECONFIG
or O_NYET; although it is perhaps a bit more "use case centric" than "what
actual effect it has" I think it might be clearer.  A -DEV, -HW or -IO suffix
would seem to needlessly preclude it being used for future similar use cases
for files that are not device nodes.

O_NYET ("not yet") is kind of attractive because it has some geekish smirk
value, doesn't have "obvious enough" meaning that if you don't know what it
does you'll guess rather than looking it up, but once you know you are not
going to forget it!  There is even precedent: USB 2 already has the NYET
packet type meaning just "not yet".  The more I'm thinking about it the more
am starting to like it...

Many of the other combinations have the problem of seeming to do the opposite
of what the used wants in some use cases; it seems rather odd to open a device
node that you are intending to configure with "O_NOCONFIG".  On the other
hand, "O_CONFIG" might be a valid indication of the intent (like O_RDONLY or
O_RDWR are indicator of intent), but also has the implication that it *will*
cause the device to configure itself.  It also would seem to imply that the
resulting file descriptor can *only* be used for that purpose.

	-hpa