IDE-Harddiskdriver for MCUs
joel@OARcorp.com
joel@OARcorp.com
Tue Jun 8 09:18:00 GMT 1999
On Mon, 7 Jun 1999, Robert J. Brown wrote:
> >>>>> "joel" == joel <joel@OARcorp.com> writes:
>
> joel> On Fri, 4 Jun 1999, Robert J. Brown wrote:
>
> >> I implemented a diskless filesystem last year for a project for
> >> a client. I did not have to write persistent data to the
> >> filesystem -- only temporary data. I also had the ability to
> >> pre-load constant files at system build time. The application
> >> was an embedded webserver with CGI capability. We talked about
> >> adding tha ability to write flash at runtime, but there are
> >> timing issues and interrupt latency problems when you do that,
> >> and we might have missed an interrupt her or there. :-(
>
> joel> One of the RTEMS uses has used the TFTP client filesystem to
> joel> download a tar image of the initial filesystem contents for
> joel> his RTEMS based web server. :)
>
> joel> Your setup sounds very similar to the RTEMS In-Memory File
> joel> System (IMFS). Our functionality goal for the IMFS may have
> joel> been a bit higher though since one of its primary purposes
> joel> was to fully exercise the filesystem infrastructure and
> joel> POSIX 1003.1b functionality. So it supports regular files,
> joel> device files, directories (readdir family), symbolic links,
> joel> permissions, etc.. We needed a filesystem that was easy to
> joel> test the entire set of system calls with and IMFS was the
> joel> result.
>
> My diskless filesystem was just as minimal as I could get and still
> get the webserver to run. I supported filenames with "/" in them like
> any other character instead of a nested directory structure. It was
> good enough to make the webserver work. I only supported open for
> read, open for write, delete, and filesize operations, as that was all
> I needed for the task at hand.
It's amazing how little it takes to actually get something useful. :)
The C library (especially newlib) is very nicely layered on top of a
handful of system calls.
Since the IMFS was developed to test eveyr feature of the filesystem
infrastructure, it is probably much more full-featured than any embedded
system would actually require in a RAM based filesystem. :)
> Because memory was tight (isn't it always?), I used a psuedo-sector
> pool and allocated sectors as needed to grow the file size. I kept
> directory entries in their own seperate structure because it was
> simpler that way. Number-of-sectors and bytes-per-sector were
> parameters that were tunable at build time, so once you knew the sizes
> of the canned files and the amount of free space, you could optimize
> the space requirements pretty well.
The IMFS simply used malloc so does not have a Number-of-sectors but there
is a bytes-per-sector like build-time parameter. I used it during testing
to run files out to the maximum size. If I used a larger allocaiton unit
size, then I did not have enough physical memory to exercise the limits of
the file system. Making the bytes-per-sector small meant that I quickly
hit the limits of the number of allowed sectors per file.
--joel
Joel Sherrill, Ph.D. Director of Research & Development
joel@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
_______________________________________________
New CrossGCC FAQ: http://www.objsw.com/CrossGCC
_______________________________________________
To remove yourself from the crossgcc list, send
mail to crossgcc-request@cygnus.com with the
text 'unsubscribe' (without the quotes) in the
body of the message.
More information about the crossgcc
mailing list