Google SOC project tinyRTEMS

Mon Mar 24 04:41:13 UTC 2008

Hello,
The newlibc's option is not functional( rtems-4.8.0 ),  it even does't
compile the newlibc stubs, so we have to do something to make it work.
 As for filesystem stubs, it do not automatically link to application,
so we also need to do something.

Redefine prink to printf is a good idea. But maybe there is a problem:
so far as I know, prink in rtems is a subset of printf, what if we
redefine prink to printf, and users use it as real printf function and
supply format specifiers that printk does't support?

And I see iwip is another project in the list, it should be an option
but in long term.

BTW: Is there any form template for us to fill in?

2008/3/24, x ray <rayx.cn at gmail.com>:
> You have found where the rub is. : )
>
> The newlibc's option you mentioned have be in the code for a time.
> However, I do not check the correctness of this code.
>
> first, let's set the object :
> (1) From developer's view, we want the newlib, file systems to be configurable
> (2) From user's view, we still need to use a small fraction of newlib
> (printf for example). And, at least. also, Ticker.exe can run without
> newlib and filesystem(ticker is more colse to a real application than
> minium).
>
> So, here is the problem, we want the code small, also we want the
> console driver. In fact, what the user really want, is printk and
> getch/putch instead of whole newlibc+filesystem which will cost them
> 2K+ sram and 4K+ ROM..
>
> What should we do?  We will have to redefine printf to printk, getch
> to BSP_getch…….. Also, made the open_dev_console to an empty function
> (see no-console.c).
>
> Also, we might want to design or include some test case for the tiny rtems.
>
> I also believed that there is something we missed in tiny rtems, that
> is lwip. I think we should put it as an option to users. (This can be
> consider as a long term goal)
>
> 2008/3/23, 阎淼 <yanmiaobest at gmail.com>:
> > 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
> >  >
> >  >
> >  >
> >  _______________________________________________
> >  rtems-users mailing list
> >  rtems-users at rtems.com
> >  http://rtems.rtems.org/mailman/listinfo/rtems-users
> >
>
>
> --
> Thanks & Best Regards!
>
> Ray, Xu
>