Re: Flames over -- Re: Which is simpler?
From: Phillip Susi
Date: Mon Feb 20 2006 - 16:44:05 EST
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/