Another scenario would be if a hotpluggable disk interface failed.
Someone could purposely move the cable to a second adaptor, before
replacing the failed one. Relevant userspace apps could be suspended
during this switch over, but when they are resumed, it would be
desirable to have the disks with the same minor numbers as before,
thereby simplifying the userspace application's requirements.
> And no, I don't want to go into the whole, remove a device and plug it
> back in, and userspace never noticed the difference while it held an
> open file handle. That's a problem I don't want to even go near right
> now, and is totally different from what udev is trying to do :)
It's also arguably better done in userspace. The kernel would see the
device disappear and re-appear, but a userspace abstraction layer
could identify it as being the same device, (and unmodified since it
last saw it), and act accordingly.
Effectively, reads from an unconnected device would succeed if the
data was cached, and writes would succeed at least until a certain
amount of write cache had been filled. The result of disconnecting a
device, modifying it's contents, then re-connecting it would be
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/