Loading application data
mike
antispam21 at verizon.net
Wed Mar 17 16:06:24 UTC 2010
Yes, there are. The default is 128 for a max file size of 4,329,344 bytes.
See /opt/rtems/rtems-4.8.1/cpukit/libfs/src/imfs/imfs.h:
* Setting IMFS_MEMFILE_BYTES_PER_BLOCK to different values has a
significant
* impact on the maximum file size supported as well as the amount of
* memory wasted due to internal file fragmentation. The following
* is a list of maximum file sizes based on various settings
*
* max_filesize with blocks of 16 is 1,328
* max_filesize with blocks of 32 is 18,656
* max_filesize with blocks of 64 is 279,488
* max_filesize with blocks of 128 is 4,329,344
* max_filesize with blocks of 256 is 68,173,568
* max_filesize with blocks of 512 is 1,082,195,456
Leontie Eugen wrote:
> Is there a limitation on the file sizes of IMFS ?
>
> I successfully used the method below for(multiple)small files, but I get errors if I try to create a file that is larger than 512k or so.
> This is not the problem of untar.
> ex.
> FILE * fp= fopen("/xxx","w");
> n=fwrite(ptr,1, 623616,fp);
> the operation only writes up to a point. n is 558080.
>
> ( I am working with the Sparc64 port so I am just trying to see if this might be a 32/64 bit issue, an insufficient sizing of some memory region or just a IMFS limitation)
>
> Eugen
> --- On Wed, 3/10/10, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
>
>
>> From: Joel Sherrill <joel.sherrill at oarcorp.com>
>> Subject: Re: Loading application data
>> To: "Eric Norum" <wenorum at lbl.gov>
>> Cc: "RTEMS" <rtems-users at rtems.org>
>> Date: Wednesday, March 10, 2010, 8:08 PM
>> On 03/10/2010 11:59 AM, Eric Norum
>> wrote:
>>
>>> I do this for my standalone EPICS applications by
>>>
>> concatenating the tar file at the end of the bootstrap
>> flash. I then set up the IMFS with the tar image
>> during my application startup with the following code.
>> The salient routine is rtems_tarfs_load. You'll
>> have to figure out some way of determining the value of the
>> tar image in memory, but once you can do that
>> rtems_tarfs_load() takes care of the rest.
>>
>>>
>>>
>> The network-demos httpd does this. It is fairly
>> straightforward.
>>
>> --joel
>>
>>> static int
>>> initialize_local_filesystem(char **argv)
>>> {
>>> extern char _DownloadLocation[]
>>>
>> __attribute__((weak));
>>
>>> extern char _FlashBase[]
>>>
>> __attribute__((weak));
>>
>>> extern char _FlashSize[]
>>>
>> __attribute__((weak));
>>
>>> if (_FlashSize&&
>>>
>> (_DownloadLocation || _FlashBase)) {
>>
>>> extern char
>>>
>> _edata[];
>>
>>> size_t flashIndex =
>>>
>> _edata - _DownloadLocation;
>>
>>> char *header =
>>>
>> _FlashBase + flashIndex;
>>
>>> if (memcmp(header +
>>>
>> 257, "ustar ", 8) == 0) {
>>
>>> int
>>>
>> fd;
>>
>>> printf
>>>
>> ("***** Unpack in-memory file system (IMFS) *****\n");
>>
>>> if
>>>
>> (rtems_tarfs_load("/", (unsigned char *)header,
>> (size_t)_FlashSize - flashIndex) != 0) {
>>
>>>
>>>
>> printf("Can't unpack tar filesystem\n");
>>
>>>
>>>
>> return 0;
>>
>>> }
>>> .........do whatever you want
>>>
>> with the IMFS at this point.........
>>
>>> }
>>> }
>>> return 0;
>>> }
>>>
>>> On Mar 10, 2010, at 9:39 AM, Gedare Bloom wrote:
>>>
>>>
>>>
>>>> Hi,
>>>>
>>>> I'm trying to figure out what is the most portable
>>>>
>> (with respect to
>>
>>>> BSP) way to get file-based data in to an
>>>>
>> application. I can't use
>>
>>>> network or ATA-type disk drive. I've had
>>>>
>> some thoughts, and was
>>
>>>> hoping someone might have faced this type of
>>>>
>> problem before me. My
>>
>>>> motivation is to do benchmarking of RTEMS systems
>>>>
>> with respect to
>>
>>>> compute and memory usage. My particular board does
>>>>
>> not support hard
>>
>>>> drive or network I/O -- and in general I would
>>>>
>> like to have a portable
>>
>>>> set of benchmarks that any other RTEMS user can
>>>>
>> use. Most of the
>>
>>>> benchmarks that I'm looking at use file i/o to get
>>>>
>> parameters for
>>
>>>> execution.
>>>>
>>>> I was looking at the various filesystems, and was
>>>>
>> intrigued by the
>>
>>>> IMFS, The Wiki says the following: "After an
>>>>
>> application restart you
>>
>>>> will need to construct its contents. RTEMS
>>>>
>> provides some supporting
>>
>>>> calls for this plus there is the ability to tar
>>>>
>> files into it." What
>>
>>>> is that bit about the ability to tar files into
>>>>
>> it? Does this require
>>
>>>> network support?
>>>>
>>>> I could try to use a RAM disk and somehow
>>>>
>> interface that with an RTEMS
>>
>>>> filesystem. Is there any support for this in
>>>>
>> RTEMS? Any idea how I
>>
>>>> would get RTEMS to know where to find the RAM
>>>>
>> disk?
>>
>>>> My last option is to convert the files that I have
>>>>
>> in to arrays of
>>
>>>> data (compressed binary/hex or ascii strings) that
>>>>
>> are stored as part
>>
>>>> of the application. This would definitely be the
>>>>
>> most portable way to
>>
>>>> get the data in to applications, but involves a
>>>>
>> bit of work
>>
>>>> translating the files to something usable by the
>>>>
>> application.
>>
>>>> Maybe someone has done something similar -- I
>>>>
>> really just need a good,
>>
>>>> portable way to get application data in to RTEMS.
>>>>
>> Although the data is
>>
>>>> currently organized in Unix files, if there are
>>>>
>> some tools to convert
>>
>>>> files in to some other format that makes it easy
>>>>
>> to place in memory
>>
>>>> alongside the RTEMS application, it would probably
>>>>
>> satisfy my
>>
>>>> constraints.
>>>>
>>>> Also, if anyone else is interested in such a set
>>>>
>> of benchmarks, let me
>>
>>>> know and I can keep you appraised of my progress.
>>>>
>>>> Thanks,
>>>> Gedare
>>>> _______________________________________________
>>>> rtems-users mailing list
>>>> rtems-users at rtems.org
>>>> http://www.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.org
>> http://www.rtems.org/mailman/listinfo/rtems-users
>>
>>
>
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>
>
>
More information about the users
mailing list