Unused sys/ucontext.h files

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Unused sys/ucontext.h files

Joseph Myers
I notice that there are files

ports/sysdeps/arm/sys/ucontext.h
ports/sysdeps/m68k/sys/ucontext.h
ports/sysdeps/mips/sys/ucontext.h

that are overridden by files in ports/sysdeps/unix/sysv/linux/<arch>, and
so unused.  Roland, is the ARM file of use for the NaCl port, or should
all three of those files be removed?

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Unused sys/ucontext.h files

Mike Frysinger
On Tuesday 21 January 2014 22:26:54 Joseph S. Myers wrote:
> I notice that there are files
>
> ports/sysdeps/arm/sys/ucontext.h
> ports/sysdeps/m68k/sys/ucontext.h
> ports/sysdeps/mips/sys/ucontext.h
>
> that are overridden by files in ports/sysdeps/unix/sysv/linux/<arch>, and
> so unused.  Roland, is the ARM file of use for the NaCl port, or should
> all three of those files be removed?

are we saying that if it's not used by Linux we're just deleting it now ?
-mike

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Unused sys/ucontext.h files

Joseph Myers
On Tue, 21 Jan 2014, Mike Frysinger wrote:

> On Tuesday 21 January 2014 22:26:54 Joseph S. Myers wrote:
> > I notice that there are files
> >
> > ports/sysdeps/arm/sys/ucontext.h
> > ports/sysdeps/m68k/sys/ucontext.h
> > ports/sysdeps/mips/sys/ucontext.h
> >
> > that are overridden by files in ports/sysdeps/unix/sysv/linux/<arch>, and
> > so unused.  Roland, is the ARM file of use for the NaCl port, or should
> > all three of those files be removed?
>
> are we saying that if it's not used by Linux we're just deleting it now ?

No, that if it's not used by any current configuration (which currently
means Hurd or Linux) it's deleted unless it's of use in bringing up a new
port ("generic" files, whether pure stubs or actual generic
implementations).  And I strongly suspect these files are just files for
whatever Unix was first supported on a given architecture - I don't really
see advantages of such files over sysdeps/generic/sys/ucontext.h in the
context of bringing up ports (which I expect would inevitably need
OS-specific versions of this file in the end).

(The sysdeps/i386/sys/ucontext.h file is, I suppose, used by Hurd, but
other <arch>/sys/ucontext.h files appear either unused, or in the am33
case maybe really a Linux file in the wrong place.)

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Unused sys/ucontext.h files

Thomas Schwinge-8
Hi!

On Wed, 22 Jan 2014 17:14:18 +0000, "Joseph S. Myers" <[hidden email]> wrote:
> (The sysdeps/i386/sys/ucontext.h file is, I suppose, used by Hurd

Correct.


Grüße,
 Thomas

attachment0 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Unused sys/ucontext.h files

Roland McGrath-4
In reply to this post by Joseph Myers
Yes, the sysdeps/arm file will (probably) be used by the arm-nacl
configuration.

In general, I am against removing files of this category just because
they are not used by any current configuration.  That is, files that are
machine-specific and for a machine that has some configurations in
current use, but are OS-independent.  I put them in the same category as
the stub files, most of which are not used by any configuration that can
be built.  Stubs of function implementations provide the outline of the
API and a starting point for filling in actual implementations.
Similarly, pure machine-specific files provide at least the basics of
the machine-specific API that should make sense across all OS
configurations of libc for that machine.

As with the stub implementations, there is of course always the danger
of bit rot.  As much as possible, all of libc's APIs are meant to be
independent of the underlying operating system.  That being the case,
people making API changes should endeavor to notice all the different
implementations and update them consistently.  People will forget, some
changes will be untested, etc.  But we should still be striving to
consider OS independence issues in all of our API choices.  Any time
there is an API whose only implementations that exist in our sources are
for a particular operating system, there is a much increased risk that
future changes will introduce or further enshrine assumptions about the
underlying operating system that make it more difficult (or impossible)
to implement that API elsewhere later on.


Thanks,
Roland