<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.18.3">
</HEAD>
<BODY>
In systems like BSD, all functions needed in kernel space must be implemented by their own.<BR>
I am not familiar with real time operation system such as RTEMS which all are running in the <BR>
same address space, so I am a little confused about using C library. <BR>
<BR>
Thanks for your reply.<BR>
<BR>
Regards<BR>
Zhongjie<BR>
<BR>
-----Original Message-----<BR>
<B>From</B>: Joel Sherrill <<A HREF="mailto:Joel%20Sherrill%20%3cjoel.sherrill@oarcorp.com%3e">joel.sherrill@oarcorp.com</A>><BR>
<B>To</B>: Zhongjie <<A HREF="mailto:Zhongjie%20%3czhurabbit@gmail.com%3e">zhurabbit@gmail.com</A>><BR>
<B>Cc</B>: Chris Johns <<A HREF="mailto:Chris%20Johns%20%3cchrisj@rtems.org%3e">chrisj@rtems.org</A>>, rtems-users@rtems.org <<A HREF="mailto:%22rtems-users@rtems.org%22%20%3crtems-users@rtems.org%3e">rtems-users@rtems.org</A>><BR>
<B>Subject</B>: Re: about header files used in score<BR>
<B>Date</B>: Mon, 15 Jun 2009 10:40:29 -0500<BR>
<BR>
<PRE>
Zhongjie wrote:
> while, I think I got what you mean.
> I think we just need to make sure the "OS proper" and BSP code do not use
> some functions from C library. It is a little hard to tell which could 
> be used and which could not be used, I think.
> One needs to know the detail implementation of the function in  the 
> library
>
Not as much as you think.  Avoid IO.  You likely won't even be
tempted to use anything else that could be troublesome.
> Is there a list about which method could be used in BSP code?
In general, string and memory methods are OK.  malloc is owned by
RTEMS and is OK after the call to libc init from bootcard.

--joel
>
> Regards
> Zhongjie
>
> On Mon, Jun 15, 2009 at 9:51 PM, Joel Sherrill 
> <<A HREF="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</A> <<A HREF="mailto:joel.sherrill@oarcorp.com">mailto:joel.sherrill@oarcorp.com</A>>> wrote:
>
>     Zhongjie wrote:
>
>         When you build gcc, you could tell gcc whether you have a c
>         library, when you tell gcc you do not have
>         a c library, gcc will define "inhibit_libc", the stdio.h
>         included by libgcc2.c is in the section with "inhibit_libc"
>         defined, when you build gcc to *-elf- or *-eabi- , such
>         arm-elf-gcc or arm-eabi-gcc, you do not need any
>         c header files for the target.
>
>     While this is true for gcc in general, when you build an rtems
>     toolset,
>     you always build the C library at the same time.  This means gcc does
>     have access to newlib.
>
>     RTEMS "OS proper" code shouldn't be depending on the C Library
>     much except for base C99 types and methods like the memory
>     and string code which doesn't require OS support.
>
>     It doesn't impact the design of the OS.  It is just a set of features
>     that are maintained by someone else and always there.
>     --joel
>
>
>         Regards
>         Zhongjie
>
>         -----Original Message-----
>         *From*: Chris Johns <<A HREF="mailto:chrisj@rtems.org">chrisj@rtems.org</A>
>         <<A HREF="mailto:chrisj@rtems.org">mailto:chrisj@rtems.org</A>>
>         <<A HREF="mailto:Chris%20Johns%20%3cchrisj@rtems.org">mailto:Chris%20Johns%20%3cchrisj@rtems.org</A>
>         <<A HREF="mailto:Chris%2520Johns%2520%253cchrisj@rtems.org">mailto:Chris%2520Johns%2520%253cchrisj@rtems.org</A>>%3e>>
>         *To*: Zhongjie <<A HREF="mailto:zhurabbit@gmail.com">zhurabbit@gmail.com</A>
>         <<A HREF="mailto:zhurabbit@gmail.com">mailto:zhurabbit@gmail.com</A>>
>         <<A HREF="mailto:Zhongjie%20%3czhurabbit@gmail.com">mailto:Zhongjie%20%3czhurabbit@gmail.com</A>
>         <<A HREF="mailto:Zhongjie%2520%253czhurabbit@gmail.com">mailto:Zhongjie%2520%253czhurabbit@gmail.com</A>>%3e>>
>         *Cc*: <A HREF="mailto:rtems-users@rtems.org">rtems-users@rtems.org</A> <<A HREF="mailto:rtems-users@rtems.org">mailto:rtems-users@rtems.org</A>>
>         <<A HREF="mailto:rtems-users@rtems.org">mailto:rtems-users@rtems.org</A> <<A HREF="mailto:rtems-users@rtems.org">mailto:rtems-users@rtems.org</A>>>
>         *Subject*: Re: about header files used in score
>         *Date*: Mon, 15 Jun 2009 09:10:59 +1000
>
>         Zhongjie wrote:
>         > thanks for reply.
>         > I am just beginning studying RTEMS, the newlib depends on a
>         limited > number of low level functions.
>
>         Welcome.
>
>         > In fact, we do not need any C library to build gcc as a
>         cross complier, > like arm-elf-gcc, only enable the c
>         > language. what I concerns is that some part of RTEMS should
>         can be > compiled using those compiler.
>
>         If you look in libgcc2.c you will see an include for stdio.h.
>         I have always needed some libc headers to build gcc.
>
>         > Of course, with newlib support, RTEMS works well, it just a
>         little > confused logically for a beginner like me.
>         > as my understanding, it is a c library depends on a os, not
>         a os depends > a c library.
>         > I think we could define those types in rtems, then included
>         by gcc and > newlib, but not use those types directly in
>         > a c library header files. it will make the architecture more
>         clearly.
>
>         GCC and newlib have all the types defined for a specific
>         target and RTEMS uses them.
>
>         Regards
>         Chris
>
>          
>
>
>
>     -- 
>     Joel Sherrill, Ph.D.             Director of Research & Development
>     <A HREF="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</A>        On-Line Applications Research
>     Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>      Support Available             (256) 722-9985
>
>
>


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


</PRE>
</BODY>
</HTML>