On Sat, Mar 7, 2009 at 7:06 PM, Andy Walls <awalls@xxxxxxxxx> wrote: > Actually it appears to be a meta-script. It builds a script of i2c-set > commands to reload an eeprom. You then have an opportunity to review > the script to reload the EEPROM and then run it. > > You first have to load the gun, then pull the trigger an shoot yourself > in the foot. :) Yeah, this is really not a very good argument. Think of the average user - he reads something on a newsgroup and thinks, "Oh, maybe my eeprom is corrupted." And then he blindly runs the three steps above. But he doesn't have the eeprom on his machine, so he copies it from someone else's dmesg output he finds on the Internet, and doesn't realize that the HVR-850 based on the Auvtiek chipset is different than the HVR-850 based on em28xx. Instant eeprom corruption. >> Do you really want to be responsible for the >> first time some unknowing user runs this against cx88 or some other >> chipset you never tried it against and it bricks their board? > > Section 11 of the GPL legally absolves the authors of most, if not all, > responsibility Perhaps "responsible" wasn't the best word to use as it implies a legal implication. Sure, you're not legally responsible, but you better feel damn responsible if you hand a tool like this to some user who is just trying to "make his device work" and he trashes it out because he doesn't know what the hell he is doing. > The script should state in big letters that EXPERT knowledge of the > device in question is required to reduce the risk. Perhaps reiterating > portions of section 11 of the GPL. (But then again, what is the risk of > a non-functioning device continuing not to function?). To answer your question, consider the definition of "non-functioning" to an average user. This can mean *anything*. He could be trying to use tvtime to watch a DVB tv source. And he runs this script and breaks a perfectly good piece of hardware. > The real risk is running the linux code that trashes the eeprom in the > first place. I would look to prevent that code from running, or at > least flag the risky condition in the kernel log. I don't doubt that this tool could be useful for a select few developers, but indeed it needs to say something like "Don't ever run this tool unless somebody who knows what the hell he is talking about tells you to". Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
