Google SOC project tinyRTEMS

[Joel Sherrill]

阎淼 wrote:
> Hello,
>
>       There are no_libc.c in libcsupport directory. In order to
> disable newlib reentrancy, application defines
> CONFIGURE_DISABLE_NEWLIB_REENTRANCY in its configuration file and link
> to libcsupport_a-nolibc.o ( maybe through manager mechanism, or add
> something like --disable-newlibc during configration process).
>        As for filesystem, put no-filesystem.o into to the final
> executable, this is the same as newlibc(add --disable-filesystem or
> treat filesystem as a manager, and application should define
> CONFIGURE_HAS_OWN_MOUNT_TABLE). But only doing this can not elimiate
> all filesystem code out, because in bsp_post_driver_hook, there is a
> function open_dev_console, which calls open to create stdin, stdout.
> The open function call will get many filesystem stuff in.  So we need
> to provide another set of std io routines( open, read, write, ioctl,
> close...maybe don't need to implement all of them ), which translate
> device name( string like "/dev/console", "/dev/rtc") to its device
> number, and use device number to find the right device driver.
>   
This is where I was saying the RTEMS 4.0.0 style device name
support would be an appropriate options. This support hinges
around rtems_io_register_name() and in old RTEMS --
rtems_io_lookup_name(). The old code is still present in
RTEMS 4.6.6 but if 0'ed out.

In that version, there was no filesystem. I think that now you
would have to have pluggable replacements for the filesystem
infrastructure that is used in open, close, etc. Then the same
system call code would be used but the underlying "filesystem"
implementation would be MUCH MUCH lighter.
>       If application needs filesystem, everything is not changed,
> device creation is through filesystem. If application does't need
> filesystem but needs stdio, it is linked to the interface just
> provided, mapping device name to  device number. If appliction does't
> need stdio and filesystem, it just gets stubs. Am I right?
>   
Yes. The rub is in making the behavior as POSIX compliant as
possible given the limitations imposed. And to make these
selections application configuration time selectable.

Look at how malloc and friends have plug-ins for various capabilities.
This is similar to how you would swap out higher and lower capability
implementations.
>
> 在 08-3-21，Joel Sherrill<joel.sherrill at oarcorp.com> 写道：
>   
>> 阎淼 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
>>
>>
>>
>>     


-- 
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