I've been reading through a disassembly of NFS 3.34 with a view to implementing configurable default fileserver and printserver, as part of my Time & Config. project.
NFS is very lax about shared absolute memory: it starts writing to &0E00 in service call 2, long before the default filesystem has been determined. It assumes the shared absolute memory is always owned by the current filesystem, only saving and restoring variables when the filesystem changes. It assumes it is the current filing system when its OSBYTES and OSWORDS are called. All this goes against the API laid down in the NAUG, as far as I can see.
It looks to me as though NFS is setting up the public workspace early in case it becomes the current filing system, even though it only claims it (and the vectors) in service call 3. If any other filing system rom does the same thing, the result will be a scrambled mess. Is this yet another "special case?"
NFS is very lax about shared absolute memory: it starts writing to &0E00 in service call 2, long before the default filesystem has been determined. It assumes the shared absolute memory is always owned by the current filesystem, only saving and restoring variables when the filesystem changes. It assumes it is the current filing system when its OSBYTES and OSWORDS are called. All this goes against the API laid down in the NAUG, as far as I can see.
It looks to me as though NFS is setting up the public workspace early in case it becomes the current filing system, even though it only claims it (and the vectors) in service call 3. If any other filing system rom does the same thing, the result will be a scrambled mess. Is this yet another "special case?"
Statistics: Posted by Barneyntd — Mon Feb 17, 2025 11:14 pm