Konamiman
commented
5 years ago some drivers will have to rely that its DEV_STATUS will be always called for media change checks
This is a wrong assumption that, admittedly, should be mentioned in the documentation.
The driver should not assume that Nextor will request device change status before accessing the device. Instead, if housekeeping is needed in case of media change, the driver itself should internally check if the media has changed before performing any access. This implies that on the next change status check request the driver will return "not changed" - but this is Nextor's problem, not the driver's.
This is how MSX-DOS works too, by the way. For example when the system boots, the kernel goes straight away to try and read the boot media without performing any change status request first.
Nextor 2.0.5-beta1 introduced the much awaited DRV_CONFIG config feature.
But there seems to be a bug on how the disk-change detection is done for removable media.
The routine MEDIA_CHECK on bank2/val.mac will only ask for the driver for a disk-change detection if the UF_PAP flag of the UD_DFLAGS isn't set. When the UF_PAP is set, MEDIA_CHECK doesn't ask for the driver and does a blind return of NC;NZ (Disk has changed).
But, when the system is booted without any media on the drive, the MAP_DEF_DEVB of the bank4/partit.mac file will set the UF_PAP flag to 1.
This behaviour causes a problem, because some drivers will have to rely that its DEV_STATUS will be always called for media change checks, so it can perform its necessary house keeping in case a media has changed, like the update of its Work Area data about the new media that is necessary for other functions like DEV_RW to perform correctly.
Since DEV_STATUS isn't being called, after the system was booted without any media in the drive, DEV_RW will fail because it doesn't know how to handle the new media yet. Nextor will then be unable to read such media and this will result in a deadlock between:
1) Nextor calling a not-yet-functional DEV_RW that to try read partition data and finally clear the UF_PAP flag, and 2) The driver waiting for Nextor to call its DEV_STATUS function to be able to update its WorkArea and make DEV_RW functional for the new media type.
For example, this is the case of SD/SDHC cards, since v1 cards and v2 cards have differences in their protocols. But there are other cases where this can happen, like USB interfaces (a completely different device might have been plugged), or even LS-120 IDE drives.