Mount other SRAM Filesystem

[Joel Sherrill]

jennifer averett wrote:
> 
> Joel Sherrill wrote:
> 
> > Sturniolo Jose wrote:
> > >
> > > Hi, I am trying to mount other memory block, SRAM, using the MOUNT function,
> > > however I can't find how to indicate the SRAM address to use.
> > >
> > > My target is:
> > > - Create a directory, called /SRAM
> > > - Mount on it, other memory area, SRAM.
> > >
> > > Any ideas? Is possible?
> >
> > At the current time, the IMFS uses memory obtained via malloc().  There
> > needs to be modifications to it for use with memory obtained via other
> > means.
> > For your case, it would be enough to define some mechanism where the
> > IMFS
> > had plug-in memory allocation routines.  Then it could get them via
> > that.
> >
> > I think long term, the best thing would be to add a parameter to the
> > mount()
> > call which allowed for filesystem specific configuration information to
> > be associated with this instantiation of the filesystem type.  This way,
> > you could mount the IMFS using malloc/free or another memory allocation
> > scheme for your SRAM.
> >
> 
> I don't think adding a parameter is the answer.  The device parameter was
> meant to be the connection between the filesystem and whatever device
> (SRAM) in this case, was controlling the memory.  There is already a
> parameter that allows filesystem specific configuraiton information to
> passed in ( rtems_filesystem_mount_table_entry_t) has a void * entry
> that is specific to the file system being mounted.  The IMFS is just
> not using this entry.

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 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.

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

[As an aside, this would be a nice feature for the network stack as
well.]
 
> Just my 2 cents
> 
> Jennifer
> 
> >
> > Does that make sense?
> >
> > Long term, there needs to be a derivative of the IMFS which does NOT
> > assume it can write directly into storage.  It should obtain blocks
> > and assume that it only has a copy of them.  This would allow it to
> > work with non-volatile storage such as flash where it can not treat
> > it like RAM.
> >
> > > Regards.
> > >
> > > Jose Sturniolo
> >
> > --
> > Joel Sherrill, Ph.D.             Director of Research & Development
> > joel at OARcorp.com                 On-Line Applications Research
> > Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> >    Support Available             (256) 722-9985

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985