Re: the remaining chunk of the RTEMS patch

[Joel Sherrill <joel dot sherrill at OARcorp dot com>]

Christopher Faylor wrote:
> 
> On Mon, Dec 11, 2000 at 08:42:40PM -0500, J. Johnston wrote:
> >Joel Sherrill wrote:
> >>
> >> I have trimmed this patch down to 700 lines.  I know it is still
> >> a bit large but it tends to boil down to a handful of interrelated
> >> things that I am having trouble separating further.  I have made
> >> every effort to make sure things were enabled only for RTEMS
> >> or based on POSIX feature flags which are currently only
> >> set for RTEMS.
> >>
> >>   + RTEMS supports a fairly full set of POSIX 1003.1b including
> >>     threads, mutexes, condition variables, and keys.  The core of
> >>     this weaves through the .h files.  So you have the addition
> >>     of pthread.h and sys/sched.h.  pthread.h being in newlib makes
> >>     that file available language run-times are built in one-tree style.
> >>   + sys/features.h is a centralized place to set all those POSIX
> >>     feature flags.  They were formerly in unistd.h.  As the set
> >>     defined by newlib targets grows, this file becomes VERY large.
> >>   + Signal stuff is augmented to include real-time signals.
> >>   + POSIX clocks and timers are added.
> >>   + unistd.h has two changes.  One is to make read, write, and
> >>     sbrk follow POSIX.  I only made read/write do this for RTEMS
> >>     because I was scared of the ramifications.  The other is
> >>     removing feature flags.
> >>
> >> New files are attached.  Feel free to change the header to make
> >> them BSD-ish licensing.  I did not know which was the accepted
> >> statement to copy.
> >>
> >>   + libc/include/pthread.h
> >>   + libc/include/sys/sched.h
> >>   + libc/include/sys/features.h
> >>
> >> If all these patches are merged, then RTEMS does not need
> >> as many target specific files.  This means the following
> >> can be removed:
> >>
> >>  + newlib/libc/sys/rtems/include/signal.h
> >>   + newlib/libc/sys/rtems/include/time.h
> >>   + newlib/libc/sys/rtems/sys/features.h
> >>   + newlib/libc/sys/rtems/sys/sched.h
> >>   + newlib/libc/sys/rtems/sys/siginfo.h
> >>   + newlib/libc/sys/rtems/sys/signal.h
> >>   + newlib/libc/sys/rtems/sys/time.h
> >>   + newlib/libc/sys/rtems/sys/times.h
> >>
> >> The changelog...
> >>
> >> 2000-12-01      Joel Sherrill <joel@OARcorp.com>
> >>
> >>         * Merge RTEMS specific .h files into main libc/include.
> >>         * libc/sys/rtems/include/signal.h: Removed.
> >>         * libc/sys/rtems/include/time.h: Removed.
> >>         * libc/sys/rtems/sys/features.h: Removed.
> >>         * libc/sys/rtems/sys/sched.h: Removed.
> >>         * libc/sys/rtems/sys/siginfo.h: Removed.
> >>         * libc/sys/rtems/sys/signal.h: Removed.
> >>         * libc/sys/rtems/sys/time.h: Removed.
> >>         * libc/sys/rtems/sys/times.h: Removed.
> >>         * libc/include/pthread.h: New file.
> >>         * libc/include/sys/sched.h: New file.
> >>         * libc/include/sys/features.h: New file.
> >>         * libc/include/time.h: Removed duplicate definition of clock_t
> >>         and time_t, get them from <sys/types.h> instead.  Add prototypes
> >>         for POSIX clock and timer functionality.
> >>         * libc/include/machine/types.h: Add _CLOCKID_T_ and _TIMER_T_.
> >>         * libc/include/sys/signal.h: Add more complete set of POSIX
> >>         signal functionality including real-time and threaded signals.
> >>         * libc/include/sys/types.h: Add clock_t, time_t, struct
> >> timespec,
> >>         and struct itimerspec.  Centralizing these makes things cleaner.
> >>         * libc/include/sys/types.h: RTEMS uses 64-bit dev_t.
> >>         * libc/include/sys/types.h: Added numerous primitive definitions
> >>         for pthreads including macros, pthread_attr_t,
> >> pthread_mutexattr_t,
> >>         pthread_condattr_t, pthread_key_t, pthread_once_t, and
> >> pthread_t.
> >>         * libc/include/sys/unistd.h: Added getlogin_r() prototype.
> >>         * libc/include/sys/unistd.h: If RTEMS follow POSIX on read() and
> >>         write() prototype.
> >>         * libc/include/sys/unistd.h: sbrk() argument is ptrdiff_t by
> >> POSIX.
> >>         * libc/include/sys/unistd.h: Feature flags removed and moved
> >>         to new file <sys/features.h>.
> >>         * libc/include/sys/unistd.h: Full set of POSIX sysconf()
> >> constants
> >>
> >
> >Patch checked in.  An additional change was required to libc/sys/linux/sys/types.h because of
> >the movement of the time_t and clock_t definitions into <sys/types.h>.  The sbrk
> >change had to protected by #if defined(__rtems__) because there are prototype conflicts elsewhere
> >in newlib and in libgloss.
> 
> This patch breaks Cygwin.
> 
> AFAICT, it removes things like '_SC_NPROCESSORS_CONF' and
> '_SC_NPROCESSORS_ONLN'.  It also seems to renumber other SC_ constants
> from their previous usage, which breaks backwards compatibility.

Where were these?  I thought I did not remove any. :(

Also AFAIK aren't these beyond POSIX?

As I have stated other times, RTEMS does not particularly care about
the numeric values.  Feel free to change them to whatever Cygwin
wants.  
 
> Can I suggest that future changes like this require verification of
> correct behavior for cygwin before they are accepted into the
> repository?  If that is not feasible then possibly we should ensure
> that cygwin at least *builds*.

If this is the case, then perhaps, newlib should be built for a standard
set of targets every N days?  You can't expect everyone submitting
patches
to build cygwin targets anymore than I can expect them to build RTEMS
targets.

> Cygwin is probably the most widely used adopter of newlib, so if newlib
> is broken with respect to Cygwin, then it is potentially impacting a lot
> of people.

I won't argue that this patch in particular and newlib in general
couldn't stand more testing but ...

Isn't this what snapshots are for?  You merge things, things break,
people
fix them.  As best I can see, it worked this time.  The patch was in
less
than 48 hours when you spotted this.  gcc has a lot of users and right
now
there is a lot of traffic regarding a large Java update breaking builds.
It happens.

Sorry for breaking things this time but I (unfortunately) expected it.
I tried to isolate things and minimize damage but that was all I could
do.

Please feel free to change the value of constants.  RTEMS does not
depend
on these in any fashion. :)
 
> cgf

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985