[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cd31fbbc-89f3-4130-9566-1e06ed6339d9@zytor.com>
Date: Sat, 15 Nov 2025 14:29:06 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Ned Ulbricht <nedu@...scape.net>, "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 2025-11-15 13:29, Ned Ulbricht wrote:
> 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.
>
I dislike O_TTY_* because restricts it to the TTY use case.
-hpa
Powered by blists - more mailing lists