Mount other SRAM Filesystem

[jennifer averett]

Joel Sherrill wrote:

> jennifer averett wrote:
> >
> > Joel Sherrill wrote:
> >
> <snip>
>
> Unless I am misreading something the
> rtems_filesystem_mount_table_entry_t
> parameter "double *" and is malloc'ed inside mount.  That means that
> user
> can't fill one in and give it as an argument to mount.  I thought it was
> meant to be the scratchpad for a filesystem to keep up with its "per
> mount"
> information.
>

My mistake, the rtems_filesystem_mount_table_entry_t is an output
of mount not an input.  Each filesystem (filesystem to mount and filesystem
where directory node exists) gets a chance to allocate anything specific
in the filesystem's mount and fsmount methods.  But these do not allow
information to be passed in.

>
> My idea was that the user could tell the IMFS which routines to call
> for malloc/free/copy.  This would at least allow the memory to come
> from somewhere besides the program heap.
>

I would rather see two methods added to rtems_filesystem_file_handlers_r,
one for allocation and one for free.  Then convert the IMFS to call these
methods for memory allocation.

>
> Did I miss something?  I was not wanting the end user to have to create
> another filesystem type just to change the malloc call.

If you do the above a new filesystem can be created with two structure
definitions and the special allocation and free methods for the SRAM.
It just doesn't seem correct to me to have the application pass in the
memory range of the device.   The application is usually oblivious to that
level of detail.

>
> <snip
> >

Jennifer