lkml.org 
[lkml]   [2006]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2006-02-20 22:48    [W:0.646 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site