Google SOC project tinyRTEMS

[阎淼]

Hi Ray, Joel,
     I see there are no-newlib, no-filesystem , no-libio in optman
directory, which can prevent linking  to real code. As the api
initialization routines, may be the core constructor is a good start
point( I have't look at the code in detail yet ).  The code size is
heavily influence by bsp code and strcuture. For example, many clock
isr call newlib fucntion atexit, which potentially calls malloc .
     I think it would be better to do link time tailoring than do it
at compile time, we build a full featured rtems, and break them down
to many libraries, and maybe a dependency file and many stubs. When
building application,we just link to what we want. And this even can
be supportive of GUI configuration project.
     As for 8bit or 16bit object-ID, we must modify the source code,
and if we do it in this way, there are many rtems features can be made
configuration items, but I am not sure if the project wants us to
modify the source.



在 08-3-22，Ray<rayx.cn at gmail.com> 写道：
> Hi, YanMiao, Joel Sherrill
> I can offer some help in this 'tiny' project if any students interested in this.
> I believe Joel also implied that we also need add some configure options that a user can choose from when he|she want to enable the file system extra. If we accomplish the 3 topic Joel gave, RTEMS can be as small as uC-OSII in a 32-bit system.
> BTW, there might something else to do e.g. 8bit or 16bit Object-ID. In a word, we want the RTEMS a more configure-able system.
> We can break the work done and make some schedule for this.
> Just keep in mind, the application will be frozen in Mar.24, hurry up!
>
>
>
>
>
> Thanks & Best Regards!
>
> Ray, rayx.cn at gmail.com
> 2008-03-22
>
>
> =========================
> ----- Receiving the following content -----
> =========================
> From:  Joel Sherrill
> Receiver:  阎淼
> Time: 2008-03-21, 21:17:43
> Subject: Re: Google SOC project tinyRTEMS
>
>
>
>
> >阎淼 wrote:
> >> Hello all,
> >>
> >>    I  am  interest  in tinyRTEMS project,  I have read the wiki page,
> >> and there are a lot of work has been done. I would like to know what
> >> is the direction of Tiny RTEMS project.
> >>
> >As stated, its goal is to shrink the minimum footprint of an RTEMS
> >executable
> >and a number of issues have already been addressed. Many of the issues are
> >fairly subtle and if you are new to RTEMS might be hard to figure out.
> >
> >One of the larger issues left and probably the only one worth even thinking
> >about as a GSOC project are the last three on the list.
> >
> >*disable newlib reentrancy (which might already be partially there)
> >*disable filesystem
> >*"device table filesystem". Functionality similar to how device names were
> >handled in RTEMS 4.0.0. Now we have a real POSIX style filesystem with
> >devices. Then we had a lookup table which mapped device names into
> >major/minor. So when you call open(), the device name isn't looked up
> >in a filesystem, it is looked up in a table of strings.
> >
> >Many of the TinyRTEMS ideas require the addition of application time
> >configuration to select the run-time capabilities. This one is a bit harder
> >because it spans the IO and filesystem infrastructure. You will have to
> >baseline
> >the size of the minimum, hello and ticker executables and work to eliminate
> >filesystem code you are replacing with a lighter alternative.
> >
> >In minimum, you want to push to have NO filesystem and IO code.
> >
> >In hello, you want the "device name lookup".
> >
> >Together the list above looks to be about 1/3-1/2 of the code in the minimum
> >executable on the ARM/Thumb rtl22xx_t BSP I use as a reference. So even
> >though
> >you might only save 8-12K total, you are moving from ~24K to 12-16K minimum.
> >
> >Does that make sense?
> >
> >
> >NOTE: Many space based systems using RTEMS do not use the filesystem and
> >hack it out anyway. This is just providing this reduced functionality
> >mode as
> >a real configure option.
> >> _______________________________________________
> >> rtems-users mailing list
> >> rtems-users at rtems.com
> >> http://rtems.rtems.org/mailman/listinfo/rtems-users
> >>
> >
> >
> >--
> >Joel Sherrill, Ph.D.             Director of Research & Development
> >joel.sherrill at OARcorp.com        On-Line Applications Research
> >Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> >   Support Available             (256) 722-9985
> >
> >
> >_______________________________________________
> >rtems-users mailing list
> >rtems-users at rtems.com
> >http://rtems.rtems.org/mailman/listinfo/rtems-users
>