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.