This is the mail archive of the ecos-patches@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] add ftok() and getenv() functions to the synthetic target


> In my case I need the DISPLAY variable in my eCos application. getenv() lives 
> in CYGPKG_LIBC_STDLIB. But the actual application doesn't need 
> CYGPKG_LIBC_STDLIB, so I would have to add a package when I compile it for 
> the synthetic target, while I don't need this package when compiling for the 
> real target. This would mean that the configuration and "environment" for the 
> same application would differ only because some utility function in the 
> synthetic target needs to access the value of a environment variable from the 
> host environment. I don't think this is a good idea.

lunn@londo:~/eCos/work$ ecosconfig new linux kernel
U CYGDBG_KERNEL_DEBUG_GDB_THREAD_SUPPORT, new inferred value 0
lunn@londo:~/eCos/work$ ecosconfig tree
lunn@londo:~/eCos/work$ make -s ; (cd kernel/current/ ; make -s tests)
headers finished
cc1: warning: command line option "-Woverloaded-virtual" is valid for C++/ObjC++ but not for C
cc1: warning: command line option "-fno-rtti" is valid for C++/ObjC++ but not for C
build finished
lunn@londo:~/eCos/work$ size install/tests/kernel/current/tests/tm_basic
   text    data     bss     dec     hex filename
  54328     416 3311708 3366452  335e34 install/tests/kernel/current/tests/tm_basic

lunn@londo:~/eCos/work$ ecosconfig add CYGPKG_LIBC_STRING CYGPKG_LIBC_I18N CYGPKG_LIBC_STDIO CYGPKG_LIBC_STDLIB
U CYGBLD_ISO_CTYPE_HEADER, new inferred value <cyg/libc/i18n/ctype.inl>
U CYGBLD_ISO_STRTOK_R_HEADER, new inferred value <cyg/libc/string/string.h>
U CYGBLD_ISO_STRING_BSD_FUNCS_HEADER, new inferred value <cyg/libc/string/bsdstring.h>
U CYGBLD_ISO_STRING_LOCALE_FUNCS_HEADER, new inferred value <cyg/libc/string/string.h>
U CYGBLD_ISO_STRING_MEMFUNCS_HEADER, new inferred value <cyg/libc/string/string.h>
U CYGBLD_ISO_STDIO_FILETYPES_HEADER, new inferred value <cyg/libc/stdio/stdio.h>U CYGBLD_ISO_STDIO_STREAMS_HEADER, new inferred value <cyg/libc/stdio/stdio.h>
U CYGBLD_ISO_STDIO_FILEOPS_HEADER, new inferred value <cyg/libc/stdio/stdio.h>
U CYGBLD_ISO_STDIO_FILEACCESS_HEADER, new inferred value <cyg/libc/stdio/stdio.h>
U CYGBLD_ISO_STDIO_FORMATTED_IO_HEADER, new inferred value <cyg/libc/stdio/stdio.h>
U CYGBLD_ISO_STDIO_CHAR_IO_HEADER, new inferred value <cyg/libc/stdio/stdio.h>
U CYGBLD_ISO_STDIO_DIRECT_IO_HEADER, new inferred value <cyg/libc/stdio/stdio.h>U CYGBLD_ISO_STDIO_FILEPOS_HEADER, new inferred value <cyg/libc/stdio/stdio.h>
U CYGBLD_ISO_STDIO_ERROR_HEADER, new inferred value <cyg/libc/stdio/stdio.h>
U CYGBLD_ISO_STDLIB_STRCONV_HEADER, new inferred value <cyg/libc/stdlib/atox.inl>
U CYGBLD_ISO_STDLIB_ABS_HEADER, new inferred value <cyg/libc/stdlib/abs.inl>
U CYGBLD_ISO_STDLIB_DIV_HEADER, new inferred value <cyg/libc/stdlib/div.inl>
U CYGBLD_ISO_STRING_STRFUNCS_HEADER, new inferred value <cyg/libc/string/string.h>
lunn@londo:~/eCos/work$ ecosconfig tree
lunn@londo:~/eCos/work$ make -s ; (cd kernel/current/ ; make -s tests)
headers finished
cc1: warning: command line option "-Woverloaded-virtual" is valid for C++/ObjC++ but not for C
cc1: warning: command line option "-fno-rtti" is valid for C++/ObjC++ but not for C
build finished
lunn@londo:~/eCos/work$ size install/tests/kernel/current/tests/tm_basic
   text    data     bss     dec     hex filename
  54328     416 3311708 3366452  335e34 install/tests/kernel/current/tests/tm_basic

Just to make it clear, here is the first size again:

   text    data     bss     dec     hex filename
  54328     416 3311708 3366452  335e34 install/tests/kernel/current/tests/tm_basic

The linker is doing its job and not including anything that is not
needed by the application.

So i see no reason why you should not include the packages you need
for synth into the build for your target application as well. It will
not affect the size of your target application.

> > As for ftok() i don't see much point in using the FreeBSD version. The
> > Linux man page tells you what it does, so why not just re-implement it
> > and save us a big license header.
> 
> That's all what the ftok man page on my system (slackware) says:
> "Typically, a best effort attempt combines the given proj_id byte, the lower 
> 16 bits of the i-node number, and the lower 8 bits of the device number into 
> a 32-bit result."

Yep, that is what is says for the man pages i have. Looking at that
description there is a very limited number of ways to implement
this. Running it with a few examples files and keys it would of been
very easy to reverse enginner the algorithm Linux is using. You then
avoid the problem that FreeBSD could be using a different algorithm to
glibc. (I presume you actually checked this?). 

        Andrew


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]