Re: [i2c-tools PATCH] tools: i2cbusses: Handle bus names like /dev/i2c-0

[Jean Delvare <jdelvare@suse.de>]

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