rtems api to the TFS filesystem (Ed's Micromonitor)

[Ed Sutter]

>> Anyway, I need to get off my butt and integrate uMon hookup into RTEMS
>> officially.  I have a relatively clean hookup procedure that I use by
>> just inserting a few files into the lib/libbsp/shared/ directory, adding
>> a call to monConnect() at the top of boot_card() and wrapping the code
>> with an #ifdef __UMON__; however I doubt that's the way to officially
>> go.
> 
> 
> Does it require any files NOT in RTEMS or it's own support to compile?

A few files are needed...  Here's exactly what I do:

1. Add a call to monConnect(MONCOMPTR,0,0) to top of boot_card()...
       #ifdef MONCOMPTR
       monConnect((int(*)())(*(unsigned long *)MONCOMPTR),(void *)0,(void *)0);
       #endif

2. Include monlib.c at the top of bootcard.c...
       #ifdef MONCOMPTR
       #include "monlib.c"
       #endif

3. Add the files monlib.c, monlib.h, tfs.h & cli.h
    (umon source files) to that directory.  Doing it this way
    eliminates the need to change any make files.

4. Then the only thing to do is externally define MONCOMPTR.  The
    value of MONCOMPTR is a board specific address; hence, really
    needs to be somewhere outside of shared.  If not defined, then
    the files in this space are unaffected.
    Putting the uMon hookup here works for me because all my boards
    boot with uMon.  Alternatively, this could be put in bspstart.c
    as part of the board specific bsp.  Then the #ifdef MONCOMPTR/#endif
    wrappers could be removed because its on a board that is known to be
    running uMon.  Perhaps this is the better location; however, then
    its duplicated for all boards that use it.

> If so, then it could be treated like other optional pieces that the 
> explicit application initialization is required before you get it
> linked in.  So the application would call monConnect() rather than
> the BSP assuming the user wants it.

The only reason I chose to put it in the BSP was because I was able to
use it to help bring up the BSP.  As soon as I call monConnect(), I have
access to uMon's API (mon_printf(), mon_memtrace(), etc...).  Helpful for
some basic debugging.

> I think that libbsp/shared is a good place if it is one or two files or 
> libbsp/shared/umon_tfs if it is more.  Then each BSP which supports umon
> will have to build it.

The only issue that I can't solve (if this is the chosen route) is where would
the definition of MONCOMPTR be put so that each BSP has the option of not
defining it?

> When the TFS is initialized how does it appear to the user?

Straight out of the box, after monConnect() is called, the entire uMon API
is available for use by the application.  This includes all of the TFS-ish
calls like: mon_tfsopen(), mon_tfsclose(), mon_tfsread(), mon_tfswrite(),
etc...
With the added RTEMS connection (using the hookup I sent Camilo), TFS will
look like any other file system hooked up to RTEMS.

Ed