Google SOC project tinyRTEMS

[阎淼]

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



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