Google SOC project tinyRTEMS
Joel Sherrill
joel.sherrill at OARcorp.com
Sat Mar 22 14:22:15 UTC 2008
阎淼 wrote:
> Hi Ray, Joel,
> I see there are no-newlib, no-filesystem , no-libio in optman
> directory, which can prevent linking to real code.
First remember that the goal with RTEMS configuration is to defer as much
as possible to when the end user application is compiled and linked. Some
things can't be done at this time but this is the goal and it is more often
doable than not doable.
But these are not integrated in a way that is easy for a user to
enable/disable.
And I do not believe they turn everything off that they should. They are a
good start but not there and not cleanly presented to the end user.
Configuration is generally hard and it must be presented in a consistent
manner in order for the many options to be manageable at the human level.
> 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 ).
Yes. This is Chris Johns idea and based upon FreeBSD. It is a very
clever way to
drop out this code. And by corollary the data that code references.
It is helpful to me to think of this as a graph and you are trying to
disconnect it.
Break a reference here and there and then add clean connector points between
the "disconnected functions".
> The code size is
> heavily influence by bsp code and strcuture. For example, many clock
> isr call newlib fucntion atexit, which potentially calls malloc .
>
Yes. This is an issue. This particular case could be easily avoided by a
couple of
side-projects.I have been slowly nibbling at. All clock drivers need to
use the
clock driver template. They include an ioctl() simply to support the
Shared Memory
MPCI driver which in turn pre-dates the Classic API Timer Manager. It is
abusing
the Clock Driver when it should use a Timer. :-D
It has long been thought that RTEMS device drivers needed a couple more
entry points. Maybe a reset and a shutdown. If this were the case, then
you wouldn't have any driver registering an atexit() handler.
> 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.
>
Since RTEMS is a library, for the most part this happens automatically
without
any GUI magic. You reference the features you want and pull them in at
link time.
Some features use indirect calls and function pointers so the linkage is
only
set at application configure/link time. This technique could easily be
used to
have a full filesystem of driver lookup filesystem and a pointer to the one
to use is set in confdefs.h.
For an example, look at some of the malloc code and its plugins. Or at
confdefs.h and how it decide which APIs have init tasks/.
> 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.
>
>
16-bit ids are already supported. There is a coinditional compilation
flag to
select it.
It is also possible that some of the rtems data types are too wide and waste
a byte or two every time they are referenced. For example, there are
not 32 bits used in the task state. :-D The performance impact of this
on 16-bit architectures would have to be evaluated but the cumulative
effect on RAM use by a review of SuperCore data types could be impressive.
Remember a task control block is ~256 bytes on most architectures. 32 bytes
from that would be more than 10%. :-D
You are getting the feel for TInyRTEMS. It isn't one thing but a long
sequence of
small steps that together make a huge difference.
--joel
>
> 在 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
>>>
--
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
More information about the users
mailing list