Ensuring generic device-level reset

[peterkrull]

I've run into a road-block trying to make my use of the library generic across different implementations of BlockDevice. The issue is that with the SdCard type, I am able to yank SD card and reinsert it, but I must call SdCard::mark_card_uninit() to force the device to re-acquire. I cannot seem to do this generically But I would also think that other implementations might have their own methods for detecting the need for a device reset. I propose two options, though I am mostly in favor of the first.

1. The BlockDevice trait could include something like a reset(&self) method. It could then either be up to the user to call reset in the case they receive a Error::DeviceError. Of course there may be implementations which do not require a reset, but for those it could just be a no-op.

2. This option would not require changing the trait, and would instead have the SdCard (and other imlpementations) handle errors which require a reset to recover from, and make the reset itself (or just mark inner.card_type = None). This would of course keep things simple, but it might require modifying the error type to allow reporting the force-reset to the user.

[thejpster]

Is it important for the volume manager to be able to tell the block device to reset, or for the block device to tell the volume manager that it has been reset?

I've been thinking about an API where the block device API gets an additional device_id: u32 argument. Hot plugging an SD Card would cause the device ID to go up by one, and so to the volume manager it would appear to be an entirely different block device.

[peterkrull]

For my suggestions the VolumeManager does not need to be changed at all. For the first point, it already exposes the underlying device through VolumeManager::device(&mut self) -> &mut D allowing the user to force-reset when they encounter a DeviceError. The second is like a silent reset on error within the BlockDevice itself. But I would also argue that the VolumeManager actually should have the ability to reset the block device, since it already has errors to describe device failure, just no way to recover from it, or even let the user do so.

To your suggestion, would you then want the BlockDevice to catch any error that may be a disconnect, force-reset itself and increment the counter? Or does the VolumeManager increment the counter on a DeviceError, causing the BlockDevice to detect it? I may not entirely understand your suggestion. In any case the BlockDevice should somehow be made aware that it should reset.