On Friday 11 July 2008, Tino Engel wrote: > Hi --HPS, > > > Hi Tino, > > > > Let's focus on getting the USB mass storage problems fixed first. > > There are plenty of USB Mass Storage IR's in the database. > > > > What kind of quirk strategy would you like to apply? > > > > If the device fails the Mass Storage test, then switch on all > > possible quirks ? Which means that the user might have to replug the > > USB device ? > > > > --HPS > > Here is a map of what I think would be reasonable: > > > At first there is a file (let's say /etc/ums.conf) which holds the > configuration of how to approach new devices. The file is delivered > with reasonable defaults. > > > GLOBAL OPTIONS: > =============== > If the option ALL_QUIRKS="YES" is set, a new UMS is approached with > all quirks. If something fails here, there is pretty much nothing left > to do. > > Also all other quirks can be set on by default: > Example: Q_NO_SYNC_CACHE="YES" would disable cache syncing for all msc > devices. > > So, now there more sophisticated part: > In case the all quirks option is not set, 2 cases remain in this model: > > CASE 1: > ======= > > Case 1 describes the case of a MSC device that hangs up > after receiving a command it could not be able to handle. It ends in a > unfixable state, even a bus reset cannot help. > > That leads us to the conclusion, the device has to be unplugged in > order to proceed. The only question is, how to proceed then. Also in > this case, the was is determined by configuration. > > The easiest case would be given by using the option: > STALLED_ALL_QUIRKS="YES" > > Then dmesg would tell to replug the device (and other events would be > triggered, for whatsoever), and all quirks would be applied for this > device from there on. The information would be held in /var/db/ums or > whatever appropriate place. > > Additionally one could think about enabling a chained quirk set: > For example I could set STALLED_Q_NO_SYNC_CACHE="1" and > STALLED_ALL_QUIRKS="2" which would have the effect, that for this > specific device, cache syncing would be disabled (quirked) on first > reconnect, and, if failed, all quirks would be activated on next > connect. dmesg would properly inform me to replug. > > Nice would also be an option STALLED_INTELLIGENCE="YES" which would try > same order as in case 2. > > The successful quirk combination is also stored in /var/db/ums. > > In addition, it would be nice to have a vendor/device specific config > format. (e.g. STALLED_Q_NO_SYNC_CACHE="SAMSUNG,1") > > This way would have the advantage that my device runs anyhow without > kernel recompilation (although i might have to replug a couple of times > in worst case :-( ) > > CASE 2: > ======= > In case 2, the device can recover by a usb reset. There it is a runtime > issue, if just all quirk permutations can be tested or if a > configuration similar to case 1 is appropriate. (I assume, we can live > with the runtime there, since plugging an usb device is not a > real-time-thing ^^) > Than we can have a nice logic (from most common to less common quirk > permutations order) > > Here we should definitely have a config file, containing device > specific quirk information, which can be updated. > > > Anyhow, feedback events (e.g. for graphical connection tools) > interaction with things like HAL and whatever comes up should be > considered, so it can be implemented sooner or later... > > > What do you think?
Hi Tino, I think this should be all automatic. Most users will have no clue what to put in those configuration files. Any others have any opinion about this on the list? --HPS _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
