On 2023-06-06 02:21, Sergey Bugaev wrote:
_hurd_port2fd and
_hurd_intern_fd are both public APIs, documented with
"FLAGS are as for `open'; only O_IGNORE_CTTY and O_CLOEXEC are meaningful"
You could change the documentation so that it now says that flags that
imply O_IGNORE_CTTY are also meaningful. That should be fine.
I think it's a good practice to always pass O_IGNORE_CTTY where
it makes sense to
Does your patch do that, for every 'open'-like call?
Maybe with GCC there is a chance, considering it's a GNU project?
Sure. I expect even 'git' will do it if you write the patch, as they
care about performance. Also tar, coreutils, grep, and other "open files
a lot" apps should benefit.
I suppose fopen could add a new 'T' flag, as a GNU extension, that would
add O_IGNORE_CTTY to the open flags.
What would be the compatibility implications of this? -- what if POSIX
later declares that 'T' must mean something else?
I wouldn't worry overmuch about that. We could ask for forgiveness later.
Thinking bigger - why does Hurd mess with this stuff at all? Wouldn't it
be better if O_IGNORE_CTTY was the default, and a different flag
(O_PAY_ATTENTION_TO_CTTY, say :-) enables the ctty dance? POSIX would
allow that behavior, as it does not require the controlling terminal to
be required if O_NOCTTY is not set.
