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] [thread-next>] [day] [month] [year] [list]

Message-ID: <6c26eea2-6f90-f48a-9488-e7480f086c70@netscape.net>
Date: Sat, 15 Nov 2025 13:29:00 -0800
From: Ned Ulbricht <nedu@...scape.net>
To: "H. Peter Anvin" <hpa@...or.com>, "Maciej W. Rozycki" <macro@...am.me.uk>
Cc: Greg KH <gregkh@...uxfoundation.org>, 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 11/14/25 10:53, H. Peter Anvin wrote:
> On November 14, 2025 10:49:09 AM PST, "Maciej W. Rozycki" <macro@...am.me.uk> wrote:
>> On Thu, 13 Nov 2025, H. Peter Anvin wrote:
>>
>>>> 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.
>>
>> Hmm, I'm inconvinced about any of these.
>>
>> How about O_FDONLY, to reflect that you are after a file descriptor only [snip]

Hi all,

Resurrecting a (private email) discussion from a few years back now, my
personal preferences are:
(1) O_KEEP
(2) O_TTY_KEEP
(3) O_TTY_NOINIT.

(Of course, naming an open() flag has got to be a paradigmatic
invitation for bike-shedding...)

It's worth pointing out, though, that even though O_TTY_INIT doesn't
generally appear in linux headers, that particular flag is documented in
POSIX to have at least incompatible --perhaps even strictly opposite--
behavior compared with this new proposed flag.

See The Open Group Base Specifications Issue 8 (IEEE Std 1003.1-2024):

| 11.1.1 Opening a Terminal Device File
|
| 3. ... The terminal parameters can be set to values that ensure the
| terminal behaves in a conforming manner by means of the O_TTY_INIT
| open flag....

https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap11.html

| open, openat — open file
|
| O_TTY_INIT

https://pubs.opengroup.org/onlinepubs/9799919799/

That's what motivates my first-glance preference to name this new flag,
which will have approximately opposite behavior, as O_TTY_NOINIT.

But as a generic abstraction, I more prefer O_KEEP.

Ned