rtems-users Digest, Vol 6, Issue 13
Yu Chen
chyyuu at gmail.com
Tue Mar 20 14:42:58 UTC 2007
>From http://code.google.com/soc/
I didn't find RTEMS project.
2007/3/15, rtems-users-request at rtems.org <rtems-users-request at rtems.org>:
> Send rtems-users mailing list submissions to
> rtems-users at rtems.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://rtems.rtems.org/mailman/listinfo/rtems-users
> or, via email, send a message with subject or body 'help' to
> rtems-users-request at rtems.com
>
> You can reach the person managing the list at
> rtems-users-owner at rtems.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of rtems-users digest..."
>
>
> Today's Topics:
>
> 1. Re: DST (Eric Norum)
> 2. Re: DST (Joel Sherrill)
> 3. RTEMS 4.7.99.1 Available (Joel Sherrill)
> 4. Google Summer of Code Update (Joel Sherrill)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 13 Mar 2007 12:10:32 -0500
> From: Eric Norum <norume at aps.anl.gov>
> Subject: Re: DST
> To: Joel Sherrill <joel.sherrill at oarcorp.com>
> Cc: Rtems-Users <rtems-users at rtems.org>
> Message-ID: <D9C81CF0-A7F7-4D2A-A381-3CD9A5AEA81F at aps.anl.gov>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
> On Mar 13, 2007, at 9:22 AM, Joel Sherrill wrote:
>
> > Eric Norum wrote:
> >> On Mar 13, 2007, at 6:29 AM, Joel Sherrill wrote:
> >>
> >>> Eric Norum wrote:
> >>>> Does the newlib that's part of RTEMS-4.7 handle the TZ
> >>>> environment variable properly? I've got:
> >>>>
> >>>> TZ="CST6CDT,M3.2.0,M11.1.0"
> >>>>
> >>>> but RTEMS is still reporting CST time.
> >>>>
> >>>>
> >>>> I built newlib from:
> >>>> NEWLIB=newlib-1.14.0
> >>>> NEWLIBDIFF=newlib-1.14.0-rtems4.7-20061019.diff
> >>>>
> >>>>
> >>> What time function are you calling?
> >>>
> >>> Internally RTEMS does not know timezone.
> >>
> >> Right, which is why I was asking about newlib. Here's a little
> >> test code I stuck into an existing application:
> >> {
> >> struct tm *tm;
> >> time_t now;
> >> printf("TZ:\"%s\"\n", getenv("TZ"));
> >> time(&now);
> >> tm = localtime(&now);
> >> printf ("%4.4d-%2.2d-%2.2d %2.2d:%2.2d:%2.2d\n", 1900+tm->tm_year,
> >> tm->tm_mon, tm->tm_mday, tm->tm_hour, tm->tm_min, tm->tm_sec);
> >> tm = gmtime(&now);
> >> printf ("%4.4d-%2.2d-%2.2d %2.2d:%2.2d:%2.2d\n", 1900+tm->tm_year,
> >> tm->tm_mon, tm->tm_mday, tm->tm_hour, tm->tm_min, tm->tm_sec);
> >> }
> >>
> >>
> >> And here's the output:
> >> TZ:"CST6CDT,M3.2.0,M11.1.0"
> >> 2007-02-13 08:04:01
> >> 2007-02-13 14:04:01
> >>
> >> The TZ variable looks right to me.
> >> The GMT values are correct. But the local time is 6 hours behind
> >> (CST) instead of 5 hours behind (CDT).
> >>
> > time() directly calls __gettimeofday_r() which is in cpukit/
> > libcsupport and has a comment
> > that newlib does not have timezone support. time() passes a NULL
> > to __gettimeofday_r()
> > so even if we did support timezone info at that level, newlib
> > wouldn't get it.
> >
> > Neither the newlib docs nor Linux man page mention timezone at all
> > for time().
> >
> > Should you be calling localtime instead of time?
>
> ???
> I *am* calling localtime() -- it's right there before the second
> printf().
>
> I think that the comment to which you are referring may, "no longer
> be operative" (gotta love those Watergate era terms). The newlib
> sources certainly have support for parsing the TZ environment
> variable. I see now what my problem was the way I had the environment
> variable set. Here's the correct format:
>
> CST6CDT,M 3.2.0,M 11.1.0
>
> The spaces after the M make all the difference!
>
> --
> Eric Norum <norume at aps.anl.gov>
> Advanced Photon Source
> Argonne National Laboratory
> (630) 252-4793
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 13 Mar 2007 12:40:59 -0500
> From: Joel Sherrill <joel.sherrill at oarcorp.com>
> Subject: Re: DST
> To: Eric Norum <norume at aps.anl.gov>
> Cc: Rtems-Users <rtems-users at rtems.org>
> Message-ID: <45F6E22B.6080700 at oarcorp.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Eric Norum wrote:
> > On Mar 13, 2007, at 9:22 AM, Joel Sherrill wrote:
> >
> >> Eric Norum wrote:
> >>> On Mar 13, 2007, at 6:29 AM, Joel Sherrill wrote:
> >>>
> >>>> Eric Norum wrote:
> >>>>> Does the newlib that's part of RTEMS-4.7 handle the TZ
> >>>>> environment variable properly? I've got:
> >>>>>
> >>>>> TZ="CST6CDT,M3.2.0,M11.1.0"
> >>>>>
> >>>>> but RTEMS is still reporting CST time.
> >>>>>
> >>>>>
> >>>>> I built newlib from:
> >>>>> NEWLIB=newlib-1.14.0
> >>>>> NEWLIBDIFF=newlib-1.14.0-rtems4.7-20061019.diff
> >>>>>
> >>>>>
> >>>> What time function are you calling?
> >>>>
> >>>> Internally RTEMS does not know timezone.
> >>>
> >>> Right, which is why I was asking about newlib. Here's a little test
> >>> code I stuck into an existing application:
> >>> {
> >>> struct tm *tm;
> >>> time_t now;
> >>> printf("TZ:\"%s\"\n", getenv("TZ"));
> >>> time(&now);
> >>> tm = localtime(&now);
> >>> printf ("%4.4d-%2.2d-%2.2d %2.2d:%2.2d:%2.2d\n", 1900+tm->tm_year,
> >>> tm->tm_mon, tm->tm_mday, tm->tm_hour, tm->tm_min, tm->tm_sec);
> >>> tm = gmtime(&now);
> >>> printf ("%4.4d-%2.2d-%2.2d %2.2d:%2.2d:%2.2d\n", 1900+tm->tm_year,
> >>> tm->tm_mon, tm->tm_mday, tm->tm_hour, tm->tm_min, tm->tm_sec);
> >>> }
> >>>
> >>>
> >>> And here's the output:
> >>> TZ:"CST6CDT,M3.2.0,M11.1.0"
> >>> 2007-02-13 08:04:01
> >>> 2007-02-13 14:04:01
> >>>
> >>> The TZ variable looks right to me.
> >>> The GMT values are correct. But the local time is 6 hours behind
> >>> (CST) instead of 5 hours behind (CDT).
> >>>
> >> time() directly calls __gettimeofday_r() which is in
> >> cpukit/libcsupport and has a comment
> >> that newlib does not have timezone support. time() passes a NULL to
> >> __gettimeofday_r()
> >> so even if we did support timezone info at that level, newlib
> >> wouldn't get it.
> >>
> >> Neither the newlib docs nor Linux man page mention timezone at all
> >> for time().
> >>
> >> Should you be calling localtime instead of time?
> >
> > ???
> > I *am* calling localtime() -- it's right there before the second
> > printf().
> >
> I need some time off. I am really stressed out trying to get all packed
> up and
> ready to leave for Munich on Friday. :(
> > I think that the comment to which you are referring may, "no longer be
> > operative" (gotta love those Watergate era terms). The newlib
> > sources certainly have support for parsing the TZ environment
> > variable. I see now what my problem was the way I had the environment
> > variable set. Here's the correct format:
> >
> > CST6CDT,M 3.2.0,M 11.1.0
> >
> > The spaces after the M make all the difference!
> >
> Fragile. :(
>
> I put together the attached init.c so we would have a reference test in
> the future. Does
> it look OK to you? FWIW tomorrow is celebrated in the local schools as
> Pi day (3/14
> in local notation) so I used 3/14 15:9:26 as the time. :)
>
> It should be self-contained. Give it a spin and I will commit it once I
> hear back.
>
> --joel
> > --Eric Norum <norume at aps.anl.gov>
> > Advanced Photon Source
> > Argonne National Laboratory
> > (630) 252-4793
> >
> >
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: init.c
> Type: text/x-csrc
> Size: 1547 bytes
> Desc: not available
> Url : http://rtems.rtems.org/pipermail/rtems-users/attachments/20070313/f53a5b33/attachment-0001.bin
>
> ------------------------------
>
> Message: 3
> Date: Tue, 13 Mar 2007 16:01:49 -0500
> From: Joel Sherrill <joel.sherrill at oarcorp.com>
> Subject: RTEMS 4.7.99.1 Available
> To: RTEMS Users Mailing List <rtems-users at rtems.org>,
> rtems-announce at rtems.org
> Message-ID: <45F7113D.4080303 at oarcorp.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi,
>
> RTEMS 4.7.99.1 is now available. This is a snapshot
> from the CVS head. It should be as stable as
> the 4.7.0 release but does include more changes which
> did not make the 4.7 release.
>
> In addition to Ralf's tireless work to get us closer
> and closer to GNU build standards, there are a number
> of changes which might impact a user:
>
> + addition of POSIX barrier, spinlock, and rwlock.
> + addition of Classic API Barrier
> (spinlock and rwlock planned)
> + public interface of libmisc services changing to
> begin with rtems_ and slowly documentation is being
> added for them to the manual set
> + When priority of blocked thread is changed, its
> placement on a priority blocking queue is reevaluated.
> + Altera NIOS II port not on 4.7 branch
>
>
> It is at ftp://ftp.rtems.org/pub/rtems/4.7.99.1
>
> Please report problems. Patches are even more welcome. :)
>
> --joel
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 13 Mar 2007 16:30:17 -0500
> From: Joel Sherrill <joel.sherrill at oarcorp.com>
> Subject: Google Summer of Code Update
> To: RTEMS Users Mailing List <rtems-users at rtems.org>
> Message-ID: <45F717E9.1020203 at oarcorp.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi,
>
> Mark sent in the RTEMS Project application yesterday.
> The Google SoC site says that projects will be announced
> on 14 March.
>
> Keep your fingers crossed. :)
>
> --joel
>
>
> ------------------------------
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>
>
> End of rtems-users Digest, Vol 6, Issue 13
> ******************************************
>
--
Best Regards
==============================================
Chen Yu
Laboratory of Pervasive Computing,
Dept. of Computer Science and Technology
Tsinghua University, Beijing 100084, P.R. China
Tel: +86 10 6278 4141 ext. 801 (Office)
E-Mail: mailto:yuchen at tsinghua.edu.cn
Web-page: http://media.cs.tsinghua.edu.cn/cn/cheny
==============================================
More information about the users
mailing list