This is the initial iteration of cleaning up simh of appending the
"footers" to disk images: it does not allow to emit any new "footers",
yet it does not change the behavior as to how any existing "footers"
are treated internally. Also, even though sim_disk.c currently builds
the "footer" for any attached disk container, with this patch, it is
only kept in-memory, and never gets written to (appended / updated)
the actual container.
If the total sectors exceeds 127Gb this is not possible, but normal
simh disks are smaller and the largest user settable size via RAUSER
is just under 1Tb. The excessive size case (>127Gb) will have a CHS
of 0xFFFF10FF.
simh never cares about the CHS Disk Geometry value in the VHD footer
data structure, but other applications which do care about the CHS
value using the previously incorrect value as the capacity of the disk
even though the Current Size indicated in the footer may have been
larger.
PDP11/pdp11_rq.c re-uses ->filebuf as a sector buffer (under the #defined
name rqxb) and allocates it as such. If an RQ disk is detached and
another attached, this buffer would be lost and the pointer reset to
NULL. sim_disk.c would only allocate the buffer if UNIT_BUFABLE is set,
which means to buffer the whole disk. Since this rightly isn't set on RQ
disks, the pointer would remain NULL and segfaults would ensue. See
open-simh issue 274.
add comment about safe re-use of filebuf
ISO files and real CDs exist which don't have ISO 9660 file structure.
These do contain ODS2 file systems since they were produced before
ISO 9660 was standardized and certainly before OS support for ISO
9660 was added. As such, any file named .iso or .ISO will always be
attached read-only since CDs are never naturally writable devices.
Updates the previous commit to do it better, by not changing
the return value of get_rsts_filesystem_size -- it still returns
the size, at least our best guess of it (for RSTS it's not possible
to get it correct in every case, but it will be correct for
most scenarios).
This is a global command possibly for folks who have configurations which
always explicitly specify the drive type they want a particular unit to be
before they attach a container to the unit. The side effect of this will
be to avoid the addition of drive type describing meta data to disk
containers.
At this time:
- The ZAP command exists to remove meta data from containers that
have it. Container files processed by the ZAP command will generally
be restored to the size it was before the addition of the meta data
and the file time stamps will be unchanged.
- Newly created containers get meta data.
- At attach time, containers that don't have meta data, but have
recognized file systems that fit within the drive it is being
attached to get meta data added without changing the file timestamps.
- Containers that don't have meta data and don't have a recognized
file system that is <= the drive size are attached without comment
and without adding meta data as long as the drive is NOT set to
autosize (controllers that support multiple drive types all default to
autosize, which can explicitly be disabled on a drive by drive basis).
- Containers that don't have meta data which are > the drive size can
only be attached read only.
- Containers with meta data can not be attached to a different
controller at all if the container size is smaller than the drive on the
other controller.
- Containers that have meta data can be freely be attached to the
controller that they were attached to when they got the meta data.
If a file system is detected, it will be reported. Otherwise if no
recognized file system is found, the attach will be silent. File
system detection reporting can be suppressed with -Q on the attach
command.
- Containers with meta data can only be attached read only to a different
controller if the container is larger than the drive it is being
attached to.
In the future:
- In general, containers with meta data (or recognized file systems)
will be attachable to MSCP and SCSI controllers, as long as reasonable
sector sizes and file system not requiring interleaving have been found.
- Containers without meta data will only be attachable if autosize
is disabled and the container is <= the size of the drive.
- Explicitly setting a drive type on a unit will implicitly disable
autosizing. If a user wants to set the default drive for a unit
and still allow autosizing they must explicitly set the unit to
autosize after setting the drive type.
Relevant to: #1065, #1059, #1094, #1100, #1118, #1117
- ZAP with -Z switch now trims all zero sectors, where the default is
to trim zero sectors added beyond the container file size when the
meta data was added.
- Remove file system wording from the skipping autosizing message.
Containers without recognized file systems already won't autosize, but now
you can't attach a container which is larger than the current drive type
presuming there is useful data beyond the size of the current drive type.
Some dependent packages on some platforms may also define HAVE_DLOPEN
and that definition may have different syntax or semantics. This change
avoids the potential symbol conflict.
As reported in #1098
- Fail ATTACH when container type doesn't match drive type and autosizing
is disabled.
- Be sure to write data at the end of a VHD container right up to the end of
the disk.
- Added rigorous disk test routine to exercise all supported disk container
formats with various sector sizes and storage element sizes
- Extended logic to validate disk container simulated device consistency
with the simulator and/or controller accessing it.
