From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
To: Sergey Bugaev <bugaevc@gmail.com>
Cc: libc-alpha@sourceware.org, bug-hurd@gnu.org,
Samuel Thibault <samuel.thibault@gnu.org>
Subject: Re: [PATCH v3 1/2] include/fcntl.h: Define O_IGNORE_CTTY
Date: Mon, 12 Jun 2023 15:56:15 -0300 [thread overview]
Message-ID: <5f5856da-d7f1-3881-7a32-3d285d3dc629@linaro.org> (raw)
In-Reply-To: <CAN9u=HdrUqeK0QFUygB85Ry1Bo=NS8zQHWAO1Ri7N2pNYBwEbw@mail.gmail.com>
On 09/06/23 06:29, Sergey Bugaev wrote:
> Hello,
>
> On Mon, Jun 5, 2023 at 9:25 PM Adhemerval Zanella Netto
> <adhemerval.zanella@linaro.org> wrote:
>> We currently are trying to avoid the
>> "#ifdef ...", so a code that does not define, where is should, would fail
>> at compile time.
>
> Yes, this makes perfect sense, and it was something I was also
> slightly concerned about (what if the Hurd's real definition stops
> being brought in by include/fcntl.h for some reason? -- then we'd just
> silently get a 0, and nobody would notice). On the other hand I wanted
> to not cause any additional troubles for other potential ports
> (FreeBSD), but maybe it's fine to require them to just add their own
> little header.
Yeah that's the idea, but by adding a generic one it would be required
iff the kernel/system needs to something differente.
>
> Do you think the Linux port should define O_IGNORE_CTTY to O_NOCTTY
> and not to 0?
Hurd O_IGNORE_CTTY and Linux O_NOCTTY do not have the *exactly* semantic,
so I think we should avoid change the internal open flags in this
specific patch.
>
>> I think it would be better to add a sysdeps/unix/sysv/linux/fcntl.h which
>> defines O_IGNORE_CTTY unconditionally and include the default one (either
>> directly or though include_next.h).
>
> Could you please clarify how this whole system of file overrides
> works? (I mean: a more specific sysdep file, for some unclear
> definition of "specific", automatically overriding a less specific
> file of the same basename.)
We have the internal header file, to say 'include/fcntl.h', which is
used when building glibc itself including the tests. The internal-only
header also includes the installed one, 'io/fcntl.h', which defines
the ABI glibc provides.
So to override a internal-only definition we have some options:
1. Override the file which is has precedence in the sysdeps selection
(which defines the -I at built time). So if you add the file
"sysdeps/unix/sysv/linux/include/fcntl.h'., it would be included
instead of 'include/fcntl.h'.
To avoid the need to replicate the same prototypes and definitions
on the generic 'include/fcntl.h' in the system specific one we
can use the include_next extension (check on how the sysvipc code
done, like include/sys/sem.h).
2. Add per-system file that is included in the generic 'include/fcntl.h',
for instance fcntl-system.h or something like that. On then add
a generic definition on sysdep/generic/ with the expected value
and override it on any sysdep folder that requires it.
I tend to see the second options as a slight simpler one.
>
> I think I've seen vpath get used somewhere, so I would guess that the
> sysdep (and other) directories are added to vpath order by their
> priority, and whichever one Make finds first, it passes to the
> compiler. Header files, I would guess again, are simply handled by
> passing all the paths (once again properly sorted) with -I, and it's
> the compiler that looks for the first directory that contains file of
> the given name -- this makes it possible to #include_next, and this
> must also be how include/ contains headers that are used during libc
> compilation but not installed (include/ must not be on the vpath
> then?).
>
> But this brings me to the more specific question: the headers to be
> installed are also found using vpath during 'make install', right? How
> would this work, will Make somehow know to not install this
> sysdeps/unix/sysv/linux/fcntl.h file that you're proposing, and keep
> installing io/fcntl.h?
Afaiu there is no need to install any new header for this, this is an
internal only definition to use on open call within glibc.
next prev parent reply other threads:[~2023-06-12 18:56 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-04 20:42 [PATCH v3 0/2] O_IGNORE_CTTY everywhere Sergey Bugaev
2023-06-04 20:42 ` [PATCH v3 1/2] include/fcntl.h: Define O_IGNORE_CTTY Sergey Bugaev
2023-06-05 18:24 ` Adhemerval Zanella Netto
2023-06-09 9:29 ` Sergey Bugaev
2023-06-12 18:56 ` Adhemerval Zanella Netto [this message]
2023-06-13 9:42 ` Sergey Bugaev
2023-06-13 13:06 ` Adhemerval Zanella Netto
2023-06-04 20:42 ` [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate Sergey Bugaev
2023-06-05 9:28 ` Florian Weimer
2023-06-05 11:55 ` Sergey Bugaev
2023-06-05 20:58 ` Paul Eggert
2023-06-06 9:21 ` Sergey Bugaev
2023-06-09 18:37 ` Paul Eggert
2023-06-09 21:13 ` Sergey Bugaev
2023-06-09 21:35 ` Paul Eggert
2023-06-10 16:13 ` Sergey Bugaev
2023-06-11 4:54 ` Paul Eggert
2023-06-13 10:54 ` Sergey Bugaev
2023-06-14 5:40 ` Paul Eggert
2023-06-16 16:26 ` Sergey Bugaev
2023-06-17 20:22 ` Paul Eggert
2023-06-18 21:55 ` Samuel Thibault
2023-06-19 8:57 ` Sergey Bugaev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5f5856da-d7f1-3881-7a32-3d285d3dc629@linaro.org \
--to=adhemerval.zanella@linaro.org \
--cc=bug-hurd@gnu.org \
--cc=bugaevc@gmail.com \
--cc=libc-alpha@sourceware.org \
--cc=samuel.thibault@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).