Indeed! It was deterministic in the sense of
1) I booted the machine 10 times and the devices came up in the same
order ;-)
2) the order of the devices was related to the usb topology, like this
(these are usb bus positions as noted by hub.c)
1/1 <- hub1
1/1/1 <- keyspan 1 /dev/ttyUSB0..3
1/1/2 <- keyspan 2 /dev/ttyUSB4..7
1/1/3 <- keyspan 3 /dev/ttyUSB8..11
1/1/4 <- hub2
1/1/4/1 <- keyspan 4 /dev/ttyUSB12..15
1/1/4/2 <- keyspan 5 /dev/ttyUSB16..19
1/1/4/3 <- keyspan 6 /dev/ttyUSB20..23
That seemed like a sensible order to me!
> What hotplug will do is allow you to assign a /dev entry to a specific
> device, so that you can go off of the topology, and not just the order
> in which the devices are found. That is how this problem will be
> solved properly.
So I'll be able to say usb bus1/1/4/1 port 3 should be /dev/ttyUSB15
and it will always be that port? That would be perfect.
> > Plugging in our USB bus with 24 devices on it does indeed produce a
> > mini-forkbomb effect ;-) (Especially since these Keyspan devices are
> > initialised twice - once without firmware and once with firmware.)
> >
> > So - perhaps hotplug ought to be serialised?
>
> No, it's not needed for this problem. There has been talk of
> serializing stuff in userspace, which is the proper way to handle some
> of the remove before add was seen problems.
Userspace serialisation would have solved this problem for us too I
think without the extra mapping mechanism.
-- Nick Craig-Wood ncw1@axis.demon.co.uk - 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/