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. > 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. -- Jean Delvare SUSE L3 Support
