> FS_Think


Locating objects within DeviceFS structure
------------------------------------------

We first check to see if the filename terminates on the '$' if it does then
we must return dummy record for the '$' record, ie. null size, its a
directory and a suitable time stamp.

This usually handled by returning load, exec and length as zero.

If the name extends beyond the specified root then we will scan the devices
list attempting to match each section correctly, returning information.

a) A directory is indicated if the leafs match upto a specified point and
   then the device record contains more data, the object is then returned
   with a directory type, gaining the access rights of the parent device.

b) A device file is returned if the object does not have anymore path
   following the matched name, we then return a 'device' file and attempt
   to make a date stamp from the time the device was registerd.

c) If the above three are not matched then the object cannot be found
   and a not found type is given.


Directory enumeration
---------------------

This is quite a simply process, firstly we locate the first object that
matches the specified path, ie. "$.<foo>", we then subtract 1 from the value
passed in r4, if the value is still +VE then we skip to the next file, this
loop continues until a suitable object has been found (ie. r4 goes -VE), we 
then copy the data into the buffer.

When the buffer is full or no more objects can be located then we reset r4
to allow enumeration to continue or not to be restarted.

Each record is word aligned.  When we have found the object we want, we call
call makeobjinfo

        returning: r0 -> path string to be copied
                   r1 -> number of characters to copy (not including term)
                   r2  = load address
                   r3  = exec address
                   r4  = access rights
                   r5  = object type


Opening an object
-----------------

First we attempt to locate the file object we want to open, we then check to 
see if it matches the device file type, if not then we do not allow the open
to occur.  It locating the file object we want to open we will be returned
the parent and device pointers (correctly setup).  We then check to see if
the open is possible, if so then we create a file node and fill in the 
relevant data.  

If we cannot open the object then we must attempt to return a suitable
error, usually handle =0.

Once we have created then file node, we then call the device, we attempt to
initalise it, we then attempt to create a buffer, setup thresholds relating
to that buffer and so on.


Closing a file
--------------

Closing a file causes the device to be shut down and the object to be
removed from the file node list.


Flushing a file
---------------

If the device is associated with a buffer then we wait for the buffer to
empty and then return.  During the wait escapes are enabled and then
restored.


Writing data
------------

Writing data, attempt to insert into buffer.  If this is not possible (ie.
not buffered) then it gets stored in the TX word, then the device gets
called to wake up (same applies for buffered/ non buffered).

The data is then read by the device (clearing the TX word if not buffered) 
and processed.  


Getting data
------------

Data is extracted from the buffer, if this fails we wait until we can get
the data, ie. the device inserts some.  If it is a non-buffered device then
we wait for the RX word to become <>-1 after asking it to wake up.

This causes the filing system to be blocked although the device records are
valid still.  Before attempting to read any data we call a RX wake up and
once the data has been obtained we call a RX close down to save band width
and misc SWIs being issued.


Device -> DeviceFS communication
--------------------------------

When a device recieves a character it then calls DeviceFS_ByteRecieved, this
then gets inserted into a buffer or placed in the RX word of the file
record.  This will eventually unblock any objects waiting on this word. 

When a device want a byte it calls DeviceFS_TransmitByte, this will attempt
to read the TX word or the buffer, if these fail then the device is marked
as dormant and should wait until the device is woken up again.


Access rights
-------------

Access rights are based on the input/output counts, if either is non-zero
then the read/write bits reflect this, eg:

        input <>0       gives read capabilities
        output <>0      gives write capabtilities

No object is ever locked.
