Re: [PATCH 4/4] ACPI: Battery: Add support for _BIX extended info method

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux