From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1PWo8c-0005yh-4c for mharc-grub-devel@gnu.org; Sun, 26 Dec 2010 05:47:42 -0500 Received: from [140.186.70.92] (port=57048 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PWo8Y-0005xX-Sv for grub-devel@gnu.org; Sun, 26 Dec 2010 05:47:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PWo8W-0003qb-Rz for grub-devel@gnu.org; Sun, 26 Dec 2010 05:47:38 -0500 Received: from mail-ww0-f49.google.com ([74.125.82.49]:55878) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PWo8W-0003qV-Jo for grub-devel@gnu.org; Sun, 26 Dec 2010 05:47:36 -0500 Received: by wwb17 with SMTP id 17so8116720wwb.30 for ; Sun, 26 Dec 2010 02:47:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type; bh=iHg0ktGZDfMlYH2Pv2MgqFP83IBNFpOC5mQFBnDalJg=; b=XhWznIElaGXEdpWS3wSWBQ+if6WBbS0VeTefTPeseoyAiu1HwKEviDSvCbxbtXasq9 TCf2MQUbKO3VLUmmiPrJXcjKV1yO/BKTgj2bD1w80l5Nxby5CDrOhks256aZMkrM6JuY 8pnEpkbcOHgs3EX2eeyjeokrGac6nvye9vGDM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; b=hgb9nswYqE3/VtdlvnP6Dy2z8T4zmYD+kH3K6FSaVHAQlCCKZZTx24LzvlkXlPaIJW xlbTZEos1UI74dvWm+Be5IOyxgmcsN7ZXAsBbI12xr7ENL6y5IsoujJoE8qWnJChLumE LdNaOWzPPuFNND/cWXS06BodC27niIclW/xX0= Received: by 10.216.47.19 with SMTP id s19mr15202717web.56.1293360454136; Sun, 26 Dec 2010 02:47:34 -0800 (PST) Received: from debian.bg45.phnet (47-30.2-85.cust.bluewin.ch [85.2.30.47]) by mx.google.com with ESMTPS id p49sm4192730wes.42.2010.12.26.02.47.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 26 Dec 2010 02:47:33 -0800 (PST) Message-ID: <4D171D34.80406@gmail.com> Date: Sun, 26 Dec 2010 11:47:16 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101211 Icedove/3.0.11 MIME-Version: 1.0 To: =?UTF-8?B?Tmljb2xhcyBkZSBQZXNsb8O8YW4=?= References: <4D0FB8A2.5060407@gmail.com> <4D15E5C9.8000501@gmail.com> <4D164CC5.1090105@gmail.com> <4D16505E.3050209@gmail.com> <4D1670F1.7080701@gmail.com> <4D167D77.3000303@gmail.com> <4D171873.2060108@gmail.com> In-Reply-To: <4D171873.2060108@gmail.com> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig1E41F7D1EA7C72593DFF9F10" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Cc: The development of GNU GRUB Subject: Re: USB bulk transfert from GRUB ? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2010 10:47:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1E41F7D1EA7C72593DFF9F10 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/26/2010 11:26 AM, Nicolas de Peslo=C3=BCan wrote: > On 12/26/2010 00:25 AM, Vladimir '=CF=86-coder/phcoder' Serbinenko wrot= e: >> On 12/25/2010 11:32 PM, Nicolas de Peslo=C3=BCan 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=3DmyUUID >> 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 updat= e >>> parts and corresponding update softwares: >>> >> Wouldn't it be a HSPA modem? Swisscom by any chance? I had one of thos= e >> 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 41= 1: > > 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. --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig1E41F7D1EA7C72593DFF9F10 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAk0XHTQACgkQNak7dOguQgl8SgD/cUOES6NE9j4MMuRDeBKb2Atm n/cEbriKoviKVFbw1iwA/3gOX32tixUR6/hc5BXgQnJwK03rE5qPcpS9dk14RT8N =r6XG -----END PGP SIGNATURE----- --------------enig1E41F7D1EA7C72593DFF9F10--