>>> so it shouldn't be really difficult to add a command to initiate a >>> given bulk transfert to a given USB endpoint. (My understanding is >>> that no such command already exists). >> grub_usb_bulk_write does exactly this. However it's not to be exported >> as a command > > Whould you support adding such command? > > usb_bulk_write <usbid> <endpoint> <string> > usb bus/address is assigned on runtime and depends on enumeration order so no way to know it in advance for sure. If usbid = vendor/device id then it's posssible although doesn't seem optimal. Which interface does usb-modeswitch use? >>> Contrary to USBModeSwitch that use a database at runtime to decide how >>> to switch the device, it is probably easier to decide this at >>> grub-mkconfig time, using the same database. >>> >> Doing any USB detection at grub-mkconfig time is a bad idea. USB is in >> flux and you can't possibly know e.g. the address of target device on >> runtime. On the other hand it should be easy to write a parser for >> device_reference.txt. > > Yes, you are right. I didn't plan to try and use a fixed USB address. > But, it sounds reasonable to assume that, for a given user, the device > is always the same (usb id). So, the usb id of the device, the > endpoint number and the string to send to the endpoint could be > selected at grub-mkconfig time and given as arguments to the grub > command I plan to create. > I still don't a clear grasp of target usecases and hence of the appropriate ways to autoconfig. >> It's also probably easier to write something that small from scratch >> than to port it (all the >> value is in the database, not code). Another question is how much >> autoconfigured it should be. >> Some people may prefer these devices be in non-storage mode as >> usually the only thing they store >> are useless buggy drivers. > > The kind of device I know provides two different modes: > > - default mode, where the device is seen as a CD reader and gives > access to a virtual CD that hold the Windows drivers for the device. > (Mostly useless, from a non Windows point of view). > - switched mode, where the device is seen as a 3G modem plus a > micro-SD card reader. I plan to boot from this micro-SD card. > > From a grub point of view, deciding to switch or to stay to the > default mode depends on whether the "kernel" one plan to boot is > located on a normal device or one a device that need to be switched > prior to be usable. > > So the switch command should only be incorporated into the menu entry > that is designed to boot on the switchable device that hold the > micro-SD card. Interesting possibility. Perhaps such devices could be scanned on runtime and we look at present files. > > And by the way, it is possible to virtually "burn" an ISO image into > the device, so it is possible to use the virtual CD reader to hold > grub. But that is another story. > I've vaguely heard that this way you can actually change the device firmware so I wouldn't exepriment with this unless I can allow myself brick the device in question (I actually have one such device) > Nicolas. >
-- Regards Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/grub-devel
