Copyright (c) 1991, 1992 by Frank J. Edwards
See the file COPYRIGHT in this distribution for copyright details.
--
12/18/91

How should directory scanning I/O be done?  It would appear that
fbread() is limited to 8K for each mapping.  So I'll have to manage
an array of such mappings; too much work -- block I/O through the
device vnode would be easier although then I have to do the seek(),
read(), seek(), write() type of scenario...

What do other filesystems use for doing file I/O?  Older ones that
haven't ben updated probably use the vnode method, newer ones will
use the memory mapping technique.  Investigate this for possibilities.
--
1/28/92

Well, at the M6/T6 tutorials we discussed segmap_getmap() and segmap_release().
These are what I should be using.  See the M6 tutorial, in the section on
VFS read() calls for details.  Also, the M6 lecture on VM has some details
on how the HAT mappings to pages work...

There were no answers to my question about dynamically allocating
physically contiguous RAM inside a device driver, but the information
was in the Motorola reference for the DDI/DKI manual.  ISBN 0-13-587692-3
for the new Motorola one, and 0-13-933680-X for the old 3B2
reference.
--
3/18/92

Well, the VFS basically works.  There is a problem with the v_count
member of the vnode contained within the anode being incremented and
never decremented.  It seems that the ados_inactive() routine is never
called.  Trace data for the s5 filesystem shows that it's inactive()
routine _is_ called, so why isn't mine!?  Must be a flag bit or something
in a structure somewhere.  I'm going to have to try to use KME to watch
a vnode for s5 and do a bit-comparison against the flag fields in my
vnode(s).  That'll be tough, to say the least.
--
11/5/92

I found that the ados_flusha() code operated different (I think that's
the routine).  In addition, the same routine was creating an infinite
loop.  The a_forw member of the anode structure was getting cleared to
NULL.  So I've temporarily set the "for" loop to terminate on NULL as
well, so that the machine at least doesn't lock up.  I've also added a
routine called "dump_chain" that displays the chain of anodes, either
free or used depending on the pointer passed in.

Dump_chain() is called at multiple points throughout the anode
allocation and freeing, and I've isolated the problem down to
ados_cache_dir().  It calls freechn(), addblk(), and walkchain().  Now
I just have to go over those routines with a fine-tooth comb and look
for the problem.  I've got the output of cflow and listings of the
offending code blocks (as identified by cflow) so I can look at the
code at any time, ie. it doesn't have to be on-line.
--
11/08/92

YEEEAAAHHHH!!  Well, I think I've got something solid.  I can mount a
filesystem (at least from the hard drive; floppy should work with the
right numbers in the vfstab).  Then I can do "ls -l" all over the
place:  the top-level directory, subdirectories, etc.  I can "chdir"
to anyplace in the tree.  (I can't write to it, of course.)  After I
cd to my AmigaDOS partition I can run the Unix zoo and list out the
contents of a .ZOO file.  I can run word count ("wc") on text files
and get the right values.  I can copy files from the partition into
a ufs or s5 filesystem and it's the right size and permissions!

If a copy an executable to /tmp I can use "arun" to execute it.  But I
can't use arun on the file directly!?  This has me confused.  All arun
does is open the file and read it in.  That should be the same as
copying the file to another location.  I'm going to have to enable the
debugging again and trace it for both cases.

But I'm going to send it to Rob anyway.  Let'im know I'm still alive. ;-)
--
11/13/92

Added a check for the existence of "fixproto" in the Makefile.
Hoepfully, if an individual doesn't have it, there won't be a
problem since execution will never be attempted...

Added the "addados" support shell script.  See ../README for details.

Need to include some kind of simple check for which version of ADOS
filesystem is being mounted.  Jan said that the "fb=" parameter is
junk since it has to be 2 to work under AmigaDOS.  Okay, then maybe
what should be in that field is "flag=DOS0" or "flag=DOS1" (or since
V3.0 is out, "flag=DOS3").  That would provide the "fb=" parameter and
allow the mount command to tell the vfs what kind of filesystem to
expect.  This may be more important later since the DOS3 filesystem
actually writes the directory caching stuff on the drive, so I'll
probably need to keep track of that.  Of course, when I have the
writable version working I could just ignore the directory cache and
always set the "bitmap invalid" flag so that AmigaDOS would have to
validate the partition...  Well, we'll see.

I've found that under DCFS the (SIZE-1) field of the root block isn't
zero where The AmigaDOS Manual (3rd Ed) says "reserved".  Instead it
had 0x0371 in it (decimal 881) which may be a pointer to the top of
the directory cache or some such.  I'm going to (mount one of my
AmigaDOS floppies!) and look at the ReleaseNotes for V39 to see if
there's any information there regarding the structure.
--
11/15/92

It appears that the very first open of any given file doesn't read the
file contents correctly.  Basically, in the getblk() routine, there's a
section where the offset is counted down and when it underflows into the
next extension block, allochn() and walkchn() are called, followed by a
loop which counts off how many data blocks are referenced by that
extension block (instead of using the field for that?).  Well, this last
loop mentioned causes the function to return an "a_idx" or 9 when it
should've been 62.  Seems like it's counting in the wrong direction...
--
11/16/92

Well, that one's been fixed now too.  Just some bad math on "idx".

I need to check the OFS routines to make sure they read data correctly,
and then start work on the read-write version of this thing.
--
11/19/92

They didn't. :-(

Turns out that during directory reads, the SMALL_BLOCK flag should be
ignored since the entire 512 bytes is necessary.  So the if stmts had
to change slightly.  No big deal really...
--
11/22/92

Keith wanted the entire file/dir heirarchy to be in one location instead
of having multiple subdirectories within /usr/sys/local.  Sounds good.

Also, the prototype files were missing and gave him an installation headache.
Okay, they are now part of the distribution and I will try to eliminate them
entirely in the future, although I do like the functionality they provide.

Keith's comment when it finally installed:  "OHMYGODITFUCKINGWORKS".  :-)

Directories should always have the execute bit enabled.  I came across a
directory the other day (on one of the V3.0 disks; Autodocs, I think)
in which a directory was shown as "drw-rw-rw-" which was pretty strange.
