Messages in this thread | | | Date | Mon, 20 Feb 2006 16:45:10 -0500 | From | Phillip Susi <> | Subject | Re: Flames over -- Re: Which is simpler? |
| |
Olivier Galibert wrote: > > If I understand USB correctly, it's all point-to-point, there is no > broadcast going on. For enumeration purposes hubs are not > transparent, and ports are separated. But I wouldn't rely on the > ports numbers on hubs to stay constant w.r.t the physical ports. I > don't think it's required. >
Hrm... that last part is crucial I think. If the kernel can tell there is a device still physically connected to the same port after the suspend, then it could reconnect that device to the existing node, and maybe notify the filesystem that the disk may have changed, so it should attempt to verify it, the way windows does.
As for the heuristics, don't most filesystems keep a mount count in the superblock? What better way to decide if things are changed than having the filesystem check that the superblock looks to be the same and specifically that it's mount count has not increased. I don't think the tests need to be that complex to get rather reasonably accurate results, and trying to put them in user space is asking for a lot of race conditions that would be solved by having the filesystem handle it.
> Since it's an hotplug bus, enumeration before suspend happened as the > devices were plugged in. So the order a reboot enumeration will see > them is unknown in practice. >
Ahh, right... I didn't think of that; the bus may have changed since the initial enumeration, so a re-enumeration will be different. I was just thinking of the case where it didn't change while suspended.
> It may be fixable by storing some kind of physical address in the > tree, but losing a filesystem because you replugged the usb drive in > the wrong physical port between suspend and resume would be annoying. > And I don't know how stable the "physical" positions are in the first > place.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |