All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Dustin Byford <dustin@cumulusnetworks.com>
Cc: Wolfram Sang <wsa@the-dreams.de>,
	linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
	jarkko.nikula@linux.intel.com, jdelvare@suse.com,
	lm-sensors@lm-sensors.org, rjw@rjwysocki.net,
	linux-acpi@vger.kernel.org
Subject: Re: [RFC 0/1] i2c: acpi: revert setting a "stable" device name
Date: Sat, 15 Aug 2015 08:13:02 -0700	[thread overview]
Message-ID: <20150815151302.GA10020@roeck-us.net> (raw)
In-Reply-To: <1439581034-5972-1-git-send-email-dustin@cumulusnetworks.com>

On Fri, Aug 14, 2015 at 12:37:13PM -0700, Dustin Byford wrote:
> 70762ab from 11/2014 (i2c: Use stable dev_name for ACPI enumerated I2C
> slaves) modified the sysfs-visible dev_name() for ACPI enumerated I2C
> devices.  With that change, /sys/bus/i2c/devices/i2c-0-004a, for
> example, became /sys/bus/i2c/devices/i2c-PNPXXXX:xx
> 
> That causes problems for userspace code such as 'sensors' which does
> this:
> 
> lib/sysfs.c:665:
> if ((!subsys || !strcmp(subsys, "i2c")) &&
>     sscanf(dev_name, "%hd-%x", &entry.chip.bus.nr,
>            &entry.chip.addr) == 2) {
> ...
> 
> Therefore, in theory, sensors that were previously visible by running
> 'sensors' no longer show up.  On the other hand, there are probably few,
> if any, cases of this because ACPI enumerated I2C hwmon devices are not
> common.
> 
> I'm not defending the 'sensors' code, I'm sure there are better ways to
> discover a hwmon I2C device from userspace.  But, I'm also not sure

Is it necessary to defend user space applications nowadays if a kernel change
breaks a well established ABI ? WHat happened to "Thou Shalt Not Break
Userspace" ?

I absolutely agree that i2c bus renumbering across reboots is a problem.
However, it seems to me that 70762ab doesn't solve that problem, it just
paints it over. And, as you have noticed, it introduces new problems along
the way.

Guenter

> 70762ab achieved its stated goal in a meaningful way.  Won't
> "i2c-<acpi_dev_name>" also vary with ACPI scan order, BIOS settings,
> firmware upgrades, etc...?
> 
> Hence the RFC patch.  To submit a change like this I would need to
> consider the fallout for ALSA SoC.  The other option is to see what can
> be done in 'sensors' to include the ACPI enumerated hwmon devices.
> 
> Any opinions on which way to go?
> 
>    --Dustin
> 
> Dustin Byford (1):
>   i2c: acpi: revert setting a "stable" device name
> 
>  drivers/i2c/i2c-core.c | 7 -------
>  1 file changed, 7 deletions(-)
> 
> -- 
> 2.1.4
> 

WARNING: multiple messages have this Message-ID (diff)
From: Guenter Roeck <linux@roeck-us.net>
To: Dustin Byford <dustin@cumulusnetworks.com>
Cc: Wolfram Sang <wsa@the-dreams.de>,
	linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
	jarkko.nikula@linux.intel.com, jdelvare@suse.com,
	lm-sensors@lm-sensors.org, rjw@rjwysocki.net,
	linux-acpi@vger.kernel.org
Subject: Re: [lm-sensors] [RFC 0/1] i2c: acpi: revert setting a "stable" device name
Date: Sat, 15 Aug 2015 15:13:02 +0000	[thread overview]
Message-ID: <20150815151302.GA10020@roeck-us.net> (raw)
In-Reply-To: <1439581034-5972-1-git-send-email-dustin@cumulusnetworks.com>

On Fri, Aug 14, 2015 at 12:37:13PM -0700, Dustin Byford wrote:
> 70762ab from 11/2014 (i2c: Use stable dev_name for ACPI enumerated I2C
> slaves) modified the sysfs-visible dev_name() for ACPI enumerated I2C
> devices.  With that change, /sys/bus/i2c/devices/i2c-0-004a, for
> example, became /sys/bus/i2c/devices/i2c-PNPXXXX:xx
> 
> That causes problems for userspace code such as 'sensors' which does
> this:
> 
> lib/sysfs.c:665:
> if ((!subsys || !strcmp(subsys, "i2c")) &&
>     sscanf(dev_name, "%hd-%x", &entry.chip.bus.nr,
>            &entry.chip.addr) = 2) {
> ...
> 
> Therefore, in theory, sensors that were previously visible by running
> 'sensors' no longer show up.  On the other hand, there are probably few,
> if any, cases of this because ACPI enumerated I2C hwmon devices are not
> common.
> 
> I'm not defending the 'sensors' code, I'm sure there are better ways to
> discover a hwmon I2C device from userspace.  But, I'm also not sure

Is it necessary to defend user space applications nowadays if a kernel change
breaks a well established ABI ? WHat happened to "Thou Shalt Not Break
Userspace" ?

I absolutely agree that i2c bus renumbering across reboots is a problem.
However, it seems to me that 70762ab doesn't solve that problem, it just
paints it over. And, as you have noticed, it introduces new problems along
the way.

Guenter

> 70762ab achieved its stated goal in a meaningful way.  Won't
> "i2c-<acpi_dev_name>" also vary with ACPI scan order, BIOS settings,
> firmware upgrades, etc...?
> 
> Hence the RFC patch.  To submit a change like this I would need to
> consider the fallout for ALSA SoC.  The other option is to see what can
> be done in 'sensors' to include the ACPI enumerated hwmon devices.
> 
> Any opinions on which way to go?
> 
>    --Dustin
> 
> Dustin Byford (1):
>   i2c: acpi: revert setting a "stable" device name
> 
>  drivers/i2c/i2c-core.c | 7 -------
>  1 file changed, 7 deletions(-)
> 
> -- 
> 2.1.4
> 

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

  parent reply	other threads:[~2015-08-15 15:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-14 19:37 [RFC 0/1] i2c: acpi: revert setting a "stable" device name Dustin Byford
2015-08-14 19:37 ` Dustin Byford
2015-08-14 19:37 ` [lm-sensors] " Dustin Byford
2015-08-14 19:37 ` [RFC 1/1] " Dustin Byford
2015-08-14 19:37   ` [lm-sensors] " Dustin Byford
2015-08-15 15:13 ` Guenter Roeck [this message]
2015-08-15 15:13   ` [lm-sensors] [RFC 0/1] " Guenter Roeck
2015-08-17  8:00   ` Jarkko Nikula
2015-08-17  8:00     ` [lm-sensors] " Jarkko Nikula
     [not found]     ` <55D1948C.6080501-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2015-08-25  5:03       ` Dustin Byford
2015-08-25  5:03         ` Dustin Byford
2015-08-25  5:03         ` [lm-sensors] " Dustin Byford

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150815151302.GA10020@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=dustin@cumulusnetworks.com \
    --cc=jarkko.nikula@linux.intel.com \
    --cc=jdelvare@suse.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lm-sensors@lm-sensors.org \
    --cc=rjw@rjwysocki.net \
    --cc=wsa@the-dreams.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.