[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Google SOC project tinyRTEMS
- Date: Mon, 24 Mar 2008 11:13:34 +0800
- From: rayx.cn at gmail.com (x ray)
- Subject: Google SOC project tinyRTEMS
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
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
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>:
> 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
Thanks & Best Regards!