On 2/06/21 7:25 pm, Jean Delvare wrote: > Hi Chris, > > On Wed, 26 May 2021 21:23:07 +0000, Chris Packham wrote: >> On 26/05/21 7:39 pm, Jean Delvare wrote: >>> I can't really see the value of this change, sorry. You want to use a >>> longer parameter so you can tab-complete it. The original parameter was >>> a 1- or 2-digit number, which is faster to type than /d<tab>i2<tab>. >>> Plus if you have multiple i2c buses, tab completion can't guess which >>> one you want anyway, so you'll have to type the bus number eventually. >>> >>> So, what do we actually win here? >> My main motivation was to replace an in-house tool that is provides >> similar functionality but it currently takes the bus as a path. At first >> I even thought there was a bug because I thought "or an I2C bus name" >> meant the path, it wasn't until I looked at the code that I realised >> this was the name used in the kernel. > OK, that's a better explanation. But I'm still not convinced by the > benefit. I'm sure you guys can learn quickly to pass just the i2c bus > number as the first parameter. Plus I don't like your implementation > for various technical reasons anyway (like allocating extra memory for > every bus when you may never actually need it, and hard-coding the > /dev/i2c-<N> pattern when there's at least one alternative supported by > i2c-tools at the moment - although I'm unsure if anyone still uses it). > So I'm not going to apply your patch, sorry. Yeah I had a few goes at implementing this. It seemed the simplest despite the memory use (which I thought probably wouldn't be a problem given the fact these tools run an then stop). I also thought about passing the argument down to the underlying open() if parsing as a number or name failed but again that would involve a fair bit of churn. >> One advantage I can see is that the /d<tab>/i2<tab> implicitly validates >> that the bus actually exists (assuming /dev is managed by devtmpfs >> and/or udev). > That's not an advantage. Running the command on the wrong I2C bus could > have bad consequences. The only safe way to use the tool without > checking the list of available i2c buses first is to select the I2C bus > by name. Yes I see your point. Mostly we use these tools for debugging broken systems anyway so "bad consequences" have already happened. Sounds like some re-training of fingers is the best approach.
