Re: [PATCH v4 1/2] i2c-tools: Allow passing device file paths

Hi Brigham,

On Thu Jul 16, 2026 at 4:49 PM CEST, Brigham Campbell wrote:
> I agree that `open_i2c_dev_path()` should be inlined, but I don't think
> it would be a good idea to remove its `fprintf()` altogether. How about
> something like the following, which would make the error messages more
> orthogonal?
>
> 	if (errno != ENOENT) {
> 		fprintf(stderr, "Error: Could not open file "
> 			"`%s': %s\n", i2cbus_arg, strerror(errno));
> 		if (errno == EACCES)
> 			fprintf(stderr, "Run as root?\n");
> 		return file;
> 	}
>
> 	fprintf(stderr, "Error: `%s' is not a bus number, name, or device file "
> 		"path!\n", i2cbus_arg);
>
> If the i2cbus_arg parameter didn't appear to be a file (ENOENT), it will
> print an error indicating that all three methods failed. If it did
> appear to be a file but couldn't open the file for whatever reason, it
> will print the error along with a suggestion to run as root if it's a
> permissions issue. This behavior reflects the behavior of
> `open_i2c_dev_by_nr()`.

I'm unsure about this: Yes, this reflects the behavior of
`open_i2c_dev_by_nr()`, but we only call that after we have validated
that the input is indeed an adapter number. With the path we don't do
that, we just try to open the input as a path. We know it's not a valid
integer, and not a valid adapter name, but it may still not be a path,
maybe it's a mistyped adapter name.

To that I'm not sure we can conclude that `errno != ENOENT` means it is
indeed a path.

Looking at libgpiod (`gpiod_chip_open_lookup()`), they solved that by
assuming that all paths must start with `/dev/`. Unsure if we want to go
that route as well. It would definitely simplify things and I think for
the sake of progress that whould be fine. Thoughts?

Best,
Gero

-- 


sevenlab engineering GmbH <https://sevenlab.de>
serious engineering.

Geschäftsführer: Christian J. Pereira
Amtsgericht Köln, HRB 121730
Anschrift: Hansaring 20, 50670 Köln