lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070506213829.GD10236@zarina>
Date:	Mon, 7 May 2007 01:38:29 +0400
From:	Anton Vorontsov <cbou@...l.ru>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	Paul Sokolovsky <pmiscml@...il.com>, ian <spyro@....com>,
	kernel-discuss@...dhelds.org, Greg KH <gregkh@...e.de>,
	linux-kernel@...r.kernel.org,
	David Woodhouse <dwmw2@...radead.org>,
	Shem Multinymous <multinymous@...il.com>
Subject: Re: [Kernel-discuss] Re: [PATCH 3/8] Universal power supply class
	(was: battery class)

On Sun, May 06, 2007 at 03:06:04PM -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 05 May 2007, Paul Sokolovsky wrote:
> > Saturday, May 5, 2007, 4:46:26 PM, you wrote:
> > > On Sat, 2007-05-05 at 00:54 -0300, Henrique de Moraes Holschuh wrote:
> > >> Given that USB-power *is* usually also "dumb" (i.e. it doesn't do any
> > >> control signaling over the USB bus for power-control purposes),
> > 
> > > it might be dumb, but it is useful to know wether the PDA is charging
> > > from usb or mains power. and some devices allow one to switch on / off
> > > the ability to charge via usb
> > 
> >         And USB does have power budgetting requirements, etc. (like
> > was already pointed in own of initial review messages). So, USB
> > is definitely not the same thing as "dumb DC".
> 
> Everything does.  A dumb DC power source is a dumb DC power source.  USB is
> no different here, *unless* it is using USB signaling to control the power
> link, at which point it is not a dumb DC power source anymore.
> 
> There really is no difference beween an AC brick, a DC brick, an AC/DC
> brick, or an USB port supplying DC power in a dumb way in a laptop or
> handheld: they are all supposed-continous DC power supplies with a maximum
> power budget.
> 
> But the "GUI should show it differently" part does make sense.  I am not
> completely convinced a high number of top-level types is the best way to go
> about it, though.  I'd use subtypes, and a comprehensive enough set of
> standard types and sub-types, along with a description of exactly what they
> are to be used for.  This will make it MUCH easier on the userspace side for
> GUI authors, and it will be much better for people to not use the wrong
> types when converting to the new class...

Um... well, if we'll speak for easiness, then just "type" is more easy and
less error-prone than type + subtype. ;-) So, personally I see nothing
wrong with MAINS/USB/Battery/UPS power supply types. Though, as you may
noticed I'm easy to convince. ;-) So, if you'll elaborate it, I might
finally will see my wrongness.


Just in case I'll be convinced...

.type = POWER_SUPPLY_TYPE_MAINS,
.subtype = POWER_SUPPLY_SUBTYPE_USB,

Looks okay?

.type = POWER_SUPPLY_TYPE_MAINS,
.subtype = POWER_SUPPLY_SUBTYPE_AC,

And SUBTYPE_AC looks not good already, because we indeed tried to
avoid AC/DC meanings in type fields, because current_type attribute
will be better. So, what subtype name we should use?

.type = POWER_SUPPLY_TYPE_BATTERY,
.subtype = POWER_SUPPLY_SUBTYPE_????,

What should be in "????" for plain batteries? Should UPS be
subtype of battery type?

.type = POWER_SUPPLY_TYPE_MAINS,
.subtype = POWER_SUPPLY_SUBTYPE_UPS,

Just wrong.


So, notice that subtype brings complications, not solves them.

Thanks!

-- 
Anton Vorontsov
email: cbou@...l.ru
backup email: ya-cbou@...dex.ru
irc://irc.freenode.org/bd2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ