On 12/25/2010 11:32 PM, Nicolas de Pesloüan wrote: > > usb-modeswitch uses vendor/device id to detect switchable devices. > I understand how it works, I meant how do you control it? > Depending on the device, the way to switch might change. Some devices > simply require an SCSI eject command to switch. Most require a bulk > transfer of a given string. Some require extra stuff. > usbms can send arbitrary SCSI command. >> I still don't a clear grasp of target usecases and hence of the >> appropriate ways to autoconfig. > > I propose to try on a "non-autoconfig" way, then decide later if we > can find a good way to autoconfig things. > It's ok to do thing partially or non-autoconf but it should be done in a way to avoid of being stuck with inconvenient interface because once a command added it can't e removed.Interesting possibility. Perhaps such devices could be scanned on >> runtime and we look at present files. > > By "look at present files", do you mean "look at the files in the ISO > image"? > Yes. Perhaps even: look for disk with UUID=myUUID if failed switch device, look again. How much overhead is switching? > The device I own (made by Option) support two totally different update > parts and corresponding update softwares: > Wouldn't it be a HSPA modem? Swisscom by any chance? I had one of those but itbroke when I've put my laptop into the bag with the modem still in USB port. > - One is the firmware, and I don't plan to update it, even if the > software to do so is easily available. > - One is the ISO image for the virtual CD reader. The software to > update the ISO image is apparently no more available, but I have a > copy of it. The software is designed to update the Windows drivers > provided by the device. > > I successfully "burn" a new ISO image, in eltorito format, that have > GRUB and /boot inside. /boot contains the kernel and an enhanced > initrd image to be able to switch the device, before accessing / from > the micro-SD. All this work. The only problem is that every time I > upgrade the kernel (/boot), I need to build and burn the ISO image again. > > In would prefer to only have a reasonably stable version of grub in > the ISO image, that only switch the device, then chainload to another > grub, Even if you make the USB device switch BIOS still won't see the new device (very few BIOSes support hotplug). Moreover it's a bad idea to revert to BIOS routines once you started sending direct USB/ATA/AHCI messages. While some form of chainloading (using multiboot) is still possible in this config I recommend against it. Just make GRUB on ISO boot linux on microSD. Current GRUB should be compatible with future linuxes > Of course, if someone want to do some reverse engineering on the > "burning" software, then it might become far more convenient to "burn" > the ISO image, removing the need for grub to be able to switch. > It's outside of GRUB scope. > But a more general framework to initiate a bulk transfer would allow > for more devices to be supported, including those which lack the > ability to update the ISO image. > > Nicolas. >
-- Regards Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/grub-devel
