From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1PWnoj-0000uI-Lw for mharc-grub-devel@gnu.org; Sun, 26 Dec 2010 05:27:09 -0500 Received: from [140.186.70.92] (port=33142 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PWnof-0000tx-G2 for grub-devel@gnu.org; Sun, 26 Dec 2010 05:27:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PWnoe-0000ML-3k for grub-devel@gnu.org; Sun, 26 Dec 2010 05:27:05 -0500 Received: from mail-wy0-f169.google.com ([74.125.82.169]:59325) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PWnod-0000MH-Rr for grub-devel@gnu.org; Sun, 26 Dec 2010 05:27:04 -0500 Received: by wyj26 with SMTP id 26so8158469wyj.0 for ; Sun, 26 Dec 2010 02:27:03 -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 :content-type:content-transfer-encoding; bh=wmCx4uDCuutFO/kcXBKBaVSq7ZsJ2zFo85NbHe1hZLk=; b=G6S7xm2twk35uxiL7NywNXsDOYoaG5yGK6KNg+m0uKM9UITw2TrDoSN2CDnrSwf5iR xxJJzrmPjrQz5QrSEaUVZ5pCMJ6K72Zha0syPOc9BsVbtWDT8WgvZmQUthVM/+q76JPy ZUTLgTl671gzSF5TXKeT6XW4dKllQEJQA7QZ8= 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:content-type:content-transfer-encoding; b=ahfwsklrLoeGo/ZK5c1mh7abmMCsAimVPerTryOEIw0Lk7embj/sBertBOFLDmrQCC xCVrKmhzJv2yr9ivsGpMQG8EK6VZtzgcfmZSfE7lgf5bLry3C/6Ts9Vn9yeyNiOyauw/ EmjiO3psm6vcjzsWU8TpBRr4JzHXbCy5j4ZOU= Received: by 10.227.162.197 with SMTP id w5mr6902845wbx.169.1293359221455; Sun, 26 Dec 2010 02:27:01 -0800 (PST) Received: from [192.168.1.13] (AReims-156-1-48-106.w86-192.abo.wanadoo.fr [86.192.223.106]) by mx.google.com with ESMTPS id m13sm7550959wbz.15.2010.12.26.02.27.00 (version=SSLv3 cipher=RC4-MD5); Sun, 26 Dec 2010 02:27:00 -0800 (PST) Message-ID: <4D171873.2060108@gmail.com> Date: Sun, 26 Dec 2010 11:26:59 +0100 From: =?UTF-8?B?Tmljb2xhcyBkZSBQZXNsb8O8YW4=?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101030 Icedove/3.0.10 MIME-Version: 1.0 To: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= 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> In-Reply-To: <4D167D77.3000303@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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:27:06 -0000 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.