Re: USB bulk transfert from GRUB ?

[Nicolas de Pesloüan]

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.

> > 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.

Yes, but unfortunately, the device I own is not switched by the SCSI eject command, but by a 
proprietary (non-SCSI) command sent using USB bulk transfer.

> > 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.

Of course, I'm currently at the "proof of concept" stage, and don't plan to have anything 
incorporated into the standard GRUB distribution until we find the right way to do it.

> > 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/

> > 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 ? The only point is that I need to "burn" an new ISO if I want to upgrade GRUB or change 
de grub.cfg file.

> > 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.

Yes, I know. Unfortunately, I think few people would have the time and the 
required skill to do so.

        Nicolas.