From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: "Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>
Cc: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: USB bulk transfert from GRUB ?
Date: Sun, 26 Dec 2010 11:47:16 +0100 [thread overview]
Message-ID: <4D171D34.80406@gmail.com> (raw)
In-Reply-To: <4D171873.2060108@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3932 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]
next prev parent reply other threads:[~2010-12-26 10:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-20 20:12 USB bulk transfert from GRUB ? Nicolas de Pesloüan
2010-12-25 12:38 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-12-25 19:57 ` Nicolas de Pesloüan
2010-12-25 20:13 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-12-25 22:32 ` Nicolas de Pesloüan
2010-12-25 23:25 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-12-26 10:26 ` Nicolas de Pesloüan
2010-12-26 10:47 ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2010-12-26 11:46 ` Nicolas de Pesloüan
2010-12-26 12:05 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-12-26 16:39 ` Nicolas de Pesloüan
2010-12-28 8:01 ` Nicolas de Pesloüan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D171D34.80406@gmail.com \
--to=phcoder@gmail.com \
--cc=grub-devel@gnu.org \
--cc=nicolas.2p.debian@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).