On Mon, 15 Mar 2010, Alexey Starikovskiy wrote: > Henrique de Moraes Holschuh ??????????: > > On Fri, 16 Oct 2009, Alan Jenkins wrote: > >> So userspace is supposed to realise that "0" means "this attribute is > >> not supported", as opposed to "I am a brand new battery and don't > >> remember being factory-tested". > >> > >> How about returning -1 for batteries without _BIX? > > > > How about NOT registering attributes that don't exist? That's the proper > > way of doing things in sysfs. > > > That is going to be too complex (2 duplicated arrays) It would be the Right Thing to do. Still, you could return a proper error as I suggested. > > When that's not possible, I'd suggest doing the right thing and returning an > > error of some sort (ENXIO, ENOTSUP, etc)... > > > None of power class members does it, and all ACPI classes are returning > -1 in not-supporting case. That just means the ACPI sysfs conversion on that area was not as good as it should have been. It is hardly the only place where the sysfs ABI is not well implemented, but that doesn't mean the breakage should remain, or that it should be made worse. What is the technical case to returning invalid values for something that is not supported when you could return a proper error on open() instead (since you're not going to do the Right Thing and not register that attribute it in the first place)? Not only the "-1" way wastes more system resources (all clients have to do open+read+close), it also needs userspace to special case something, and that is always a Bad Idea for *many* reasons. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html