Dan Williams <[EMAIL PROTECTED]> wrote on 06/03/2008 01:20:11 PM: > On Tue, 2008-06-03 at 13:03 -0400, Michail Bletsas wrote: > > Dan Williams <[EMAIL PROTECTED]> wrote on 06/03/2008 11:26:21 AM: > > > > > > > > > > > > > It is not a matter of Python vs C. > > > > The userspace tool is extremely awkward to use (since it requires the > > > > driver modules to be unloaded which in turn makes the identification > > of > > > > > > How does it make the ID more difficult? What do we need besides the > > > bcdDevice ID that tells us what boot2 version the device has? Is there > > > something more needed to find out if the device has larger EEPROM for > > > active antenna support perhaps? > > > > It makes it more difficult because instead of network interfaces (eth0, > > eth1 etc), one ends up having to deal with USB ids. > > In devices with multiple intefaces (an XO with an active antenna for > > example), that is very confusing. > > This is fair; except that the network interface name is subject to > change and you can't guarantee that eth0 will always be the same device > unless you use something like udev rules to rename devices on the fly > when they are plugged in based on the device's MAC address, which > requires loading the driver first. The kernel has never had a guarantee > about device ordering. > > So if you _really_ want to make sure you're updating the right device, > then you get Marvell to start putting real serial #s into the USB > interface's serial number slot instead of 0. My usb8388 says: > > bcdDevice 31.02 > iManufacturer 1 Marvell > iProduct 2 MARVELL Wireless Device > iSerial 0 <------------------------- > bNumConfigurations 1 > > that's the only way to guarantee that you're updating the device you > want to update. > That's a good suggestion. >From a practical perspective though, in XOs, the onboard interface is always eth0 these days.
M. _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
