From: Guenter Roeck <linux@roeck-us.net> To: Pavel Machek <pavel@ucw.cz> Cc: Zhang Rui <rui.zhang@intel.com>, pali.rohar@gmail.com, sre@kernel.org, kernel list <linux-kernel@vger.kernel.org>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, linux-omap@vger.kernel.org, tony@atomide.com, khilman@kernel.org, aaro.koskinen@iki.fi, ivo.g.dimitrov.75@gmail.com, patrikbachan@gmail.com, serge@hallyn.com, abcloriens@gmail.com, fabio.estevam@nxp.com Subject: Re: v4.10-rc4 to v4.10-rc5: battery regression on Nokia N900 Date: Tue, 24 Jan 2017 10:45:26 -0800 [thread overview] Message-ID: <20170124184526.GA25056@roeck-us.net> (raw) In-Reply-To: <20170124175800.GA15070@amd> On Tue, Jan 24, 2017 at 06:58:01PM +0100, Pavel Machek wrote: > > > >>Right. > > >> > > >>Before reverting, can you please try if this patch works or not? > > > > > >Not really. Revert now. Sorry. > > > > > >Are you sure? This does not look equivalent to me at all. > > > > > >"name" file handling moved from drivers to the core, which added some > > >crazy checks what name can contain. Even if this "works", what is the > > >expected effect on the "name" file? > > > > > The hwmon name attribute must not include '-', as documented in > > Documentation/hwmon/sysfs-interface. Is enforcing that 'crazy' ? > > Maybe in your world, but not in mine. > > Well, lets revert the patch and then we can discuss what to do with > the "name" problem. > Not sure what the problem to be discussed is. Please provide details. > Unfortunately, code enforces different rules than documentation says, Please specify your problem with rules vs. documentation. You mean the additional checks which also block wildcards and spaces/newline in the name ? Are you having a problem with those ? What are those problems ? I'll be more than happy to update the documentation if your problem is with that mismatch. To provide some detail: libsensors gets just as confused with wildcards and whitespace/newline as it does with '-' in the reported name, which is why those are blocked by the new API. > and it is all visible to userspace. > We are talking about a value reported by an attribute, not about an attribute. Maybe the ABI Police thinks differently, but I do not count fixing the value reported by an attribute as an ABI change. Effecively, what this enforcement does is to make userspace actually work. Ultimately that means, per your standard, that fixing values reported by the kernel is not permitted under any circumstances, even if such changes result in userspace actually working as intended as a result of that change. I would argue that such an enforcement goes a little bit too far. In addition, there is actually another problem solved by the patch you want to have reverted: The current thermal code has another problem, which is that it creates the name attribute _after_ registering the hwmon device. The udev event for creating the hwmon device thus occurs before its mandatory name attribute (and any other attribute, for that matter) exists, meaning that any userspace handler acting on it would be completely unpredictable. Now _this_ is a real ABI "change", since it fixes a race condition. I guess you are going to argue that this isn't permitted either ? Guenter
WARNING: multiple messages have this Message-ID (diff)
From: linux@roeck-us.net (Guenter Roeck) To: linux-arm-kernel@lists.infradead.org Subject: v4.10-rc4 to v4.10-rc5: battery regression on Nokia N900 Date: Tue, 24 Jan 2017 10:45:26 -0800 [thread overview] Message-ID: <20170124184526.GA25056@roeck-us.net> (raw) In-Reply-To: <20170124175800.GA15070@amd> On Tue, Jan 24, 2017 at 06:58:01PM +0100, Pavel Machek wrote: > > > >>Right. > > >> > > >>Before reverting, can you please try if this patch works or not? > > > > > >Not really. Revert now. Sorry. > > > > > >Are you sure? This does not look equivalent to me at all. > > > > > >"name" file handling moved from drivers to the core, which added some > > >crazy checks what name can contain. Even if this "works", what is the > > >expected effect on the "name" file? > > > > > The hwmon name attribute must not include '-', as documented in > > Documentation/hwmon/sysfs-interface. Is enforcing that 'crazy' ? > > Maybe in your world, but not in mine. > > Well, lets revert the patch and then we can discuss what to do with > the "name" problem. > Not sure what the problem to be discussed is. Please provide details. > Unfortunately, code enforces different rules than documentation says, Please specify your problem with rules vs. documentation. You mean the additional checks which also block wildcards and spaces/newline in the name ? Are you having a problem with those ? What are those problems ? I'll be more than happy to update the documentation if your problem is with that mismatch. To provide some detail: libsensors gets just as confused with wildcards and whitespace/newline as it does with '-' in the reported name, which is why those are blocked by the new API. > and it is all visible to userspace. > We are talking about a value reported by an attribute, not about an attribute. Maybe the ABI Police thinks differently, but I do not count fixing the value reported by an attribute as an ABI change. Effecively, what this enforcement does is to make userspace actually work. Ultimately that means, per your standard, that fixing values reported by the kernel is not permitted under any circumstances, even if such changes result in userspace actually working as intended as a result of that change. I would argue that such an enforcement goes a little bit too far. In addition, there is actually another problem solved by the patch you want to have reverted: The current thermal code has another problem, which is that it creates the name attribute _after_ registering the hwmon device. The udev event for creating the hwmon device thus occurs before its mandatory name attribute (and any other attribute, for that matter) exists, meaning that any userspace handler acting on it would be completely unpredictable. Now _this_ is a real ABI "change", since it fixes a race condition. I guess you are going to argue that this isn't permitted either ? Guenter
next prev parent reply other threads:[~2017-01-24 18:45 UTC|newest] Thread overview: 97+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-01-23 12:40 v4.10-rc4 to v4.10-rc5: battery regression on Nokia N900 Pavel Machek 2017-01-23 12:40 ` Pavel Machek 2017-01-23 12:42 ` Pali Rohár 2017-01-23 12:42 ` Pali Rohár 2017-01-23 14:20 ` Pavel Machek 2017-01-23 14:20 ` Pavel Machek 2017-01-23 14:19 ` Pavel Machek 2017-01-23 14:19 ` Pavel Machek 2017-01-23 14:31 ` Guenter Roeck 2017-01-23 14:31 ` Guenter Roeck 2017-01-23 14:40 ` Pavel Machek 2017-01-23 14:40 ` Pavel Machek 2017-01-23 17:10 ` Guenter Roeck 2017-01-23 17:10 ` Guenter Roeck 2017-01-23 23:26 ` Pavel Machek 2017-01-23 23:26 ` Pavel Machek 2017-01-23 23:49 ` Guenter Roeck 2017-01-23 23:49 ` Guenter Roeck 2017-01-24 7:06 ` Zhang Rui 2017-01-24 7:06 ` Zhang Rui 2017-01-24 7:37 ` Pavel Machek 2017-01-24 7:37 ` Pavel Machek 2017-01-24 14:18 ` Guenter Roeck 2017-01-24 14:18 ` Guenter Roeck 2017-01-24 17:58 ` Pavel Machek 2017-01-24 17:58 ` Pavel Machek 2017-01-24 18:45 ` Guenter Roeck [this message] 2017-01-24 18:45 ` Guenter Roeck 2017-01-24 22:46 ` Pavel Machek 2017-01-24 22:46 ` Pavel Machek 2017-01-24 23:07 ` Fabio Estevam 2017-01-24 23:07 ` Fabio Estevam 2017-01-25 5:29 ` Zhang Rui 2017-01-25 5:29 ` Zhang Rui 2017-01-25 10:17 ` Pavel Machek 2017-01-25 10:17 ` Pavel Machek 2017-01-25 11:12 ` Pavel Machek 2017-01-25 11:12 ` Pavel Machek 2017-01-25 11:51 ` Guenter Roeck 2017-01-25 11:51 ` Guenter Roeck 2017-01-25 11:51 ` Guenter Roeck 2017-01-25 12:09 ` Pali Rohár 2017-01-25 12:09 ` Pali Rohár 2017-01-27 1:37 ` Zhang Rui 2017-01-27 1:37 ` Zhang Rui 2017-01-27 1:37 ` Zhang Rui 2017-01-27 2:03 ` Guenter Roeck 2017-01-27 2:03 ` Guenter Roeck 2017-01-27 3:39 ` Zhang Rui 2017-01-27 3:39 ` Zhang Rui 2017-01-27 3:39 ` Zhang Rui 2017-01-27 6:27 ` Guenter Roeck 2017-01-27 6:27 ` Guenter Roeck 2017-01-27 6:27 ` Guenter Roeck 2017-01-27 11:16 ` Pavel Machek 2017-01-27 11:16 ` Pavel Machek 2017-01-27 14:13 ` Guenter Roeck 2017-01-27 14:13 ` Guenter Roeck 2017-01-27 19:06 ` Pavel Machek 2017-01-27 19:06 ` Pavel Machek 2017-01-27 19:06 ` Pavel Machek 2017-01-27 14:40 ` Zhang Rui 2017-01-27 14:40 ` Zhang Rui 2017-01-27 17:20 ` Guenter Roeck 2017-01-27 17:20 ` Guenter Roeck 2017-01-27 19:12 ` Pavel Machek 2017-01-27 19:12 ` Pavel Machek 2017-01-27 19:12 ` Pavel Machek 2017-01-27 19:29 ` Pavel Machek 2017-01-27 19:29 ` Pavel Machek 2017-01-27 19:29 ` Pavel Machek 2017-01-27 8:35 ` Pali Rohár 2017-01-27 8:35 ` Pali Rohár 2017-01-27 11:09 ` Pavel Machek 2017-01-27 11:09 ` Pavel Machek 2017-01-27 11:09 ` Pavel Machek 2017-01-27 14:14 ` Guenter Roeck 2017-01-27 14:14 ` Guenter Roeck 2017-01-27 14:14 ` Guenter Roeck 2017-01-27 19:02 ` Pavel Machek 2017-01-27 19:02 ` Pavel Machek 2017-01-27 19:02 ` Pavel Machek 2017-01-27 11:29 ` Pavel Machek 2017-01-27 11:29 ` Pavel Machek 2017-01-24 14:10 ` Guenter Roeck 2017-01-24 14:10 ` Guenter Roeck 2017-01-24 14:15 ` Pavel Machek 2017-01-24 14:15 ` Pavel Machek 2017-01-24 14:30 ` Guenter Roeck 2017-01-24 14:30 ` Guenter Roeck 2017-01-24 7:34 ` Pavel Machek 2017-01-24 7:34 ` Pavel Machek 2017-01-24 14:15 ` Guenter Roeck 2017-01-24 14:15 ` Guenter Roeck 2017-01-23 20:22 ` Pavel Machek 2017-01-23 20:22 ` Pavel Machek 2017-01-23 20:22 ` Pavel Machek
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=20170124184526.GA25056@roeck-us.net \ --to=linux@roeck-us.net \ --cc=aaro.koskinen@iki.fi \ --cc=abcloriens@gmail.com \ --cc=fabio.estevam@nxp.com \ --cc=ivo.g.dimitrov.75@gmail.com \ --cc=khilman@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=pali.rohar@gmail.com \ --cc=patrikbachan@gmail.com \ --cc=pavel@ucw.cz \ --cc=rui.zhang@intel.com \ --cc=serge@hallyn.com \ --cc=sre@kernel.org \ --cc=tony@atomide.com \ /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: linkBe 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.