On 12/26/2010 11:26 AM, Nicolas de Pesloüan wrote:
> On 12/26/2010 00:25 AM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> 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?
>
> Sorry, but I don't understand your question. I don't "control"
> usb-modeswitch nor "control" de device. udev, when detecting the
> device, calls the usb-modeswitch executable, that in turn switchs the
> device based on it vendor/device id and a database of the well known
> devices that need to be switched. If I don't want the device to be
> switched, I need to remove the udev rule for the device.
>
That's what I wanted to know. So you modify udev rules to control the
behaviour of switching. Not really applicable to GRUB. Perhaps one would
use a reduced database with only the devices one wants to switch?
>>> 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?
>
> Interesting. Do you mean that is might be better to add an extra
> option to the search command, for example "--switch-on-failure"? And
> use the usb-modeswitch database inside the search command, to do
> whatever is required to switch devices?
>
> This may lead to switching several devices (if several are connected
> at boot time), which might be undesirable. I think we should avoid
> switching any device except the one(s) which is/are clearly necessary
> to access the volume(s) we plan to boot from. Other devices would be
> switched later, by the operating system, if appropriate.
>
> So I think we need two different options for search command :
>
> --switch-all
> --switch vendor-id:device-id
>
> The first (and most used) one would switch all switchable device
> before search (or after a first failed search).
> The second one would switch only a particular device and would be used
> for the arguably very special case where we don't want all switchable
> devices to be switched.
>
> The overhead of switching is not really major but not negligible. From
> a system point of view, it is seen a unpluging an USB device and
> pluging another one.
>
>>> 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.
>
> The device I own is a Vodafone K3760, which really is an Option Icon 411:
>
> http://www.option.com/en/products/products/usb-modems/icon411/
>
Probably the same as swisscom one.
>>> 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
>
> If I properly understand, you recommend not to chainload to another
> grub (because chainload uses BIOS int13h ?), but there is no problem
> directly booting the OS in the micro-SD from GRUB on the ISO. Right ?
Right
> The only point is that I need to "burn" an new ISO if I want to
> upgrade GRUB or change de grub.cfg file.
>
you can even have grub.cfg on microSD using configfile directive.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko