Re: [PATCH v3 1/2] include/fcntl.h: Define O_IGNORE_CTTY

[Adhemerval Zanella Netto]

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.