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: <200701261902.38247.david-b@pacbell.net>
Date:	Fri, 26 Jan 2007 19:02:37 -0800
From:	David Brownell <david-b@...bell.net>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Greg KH <gregkh@...e.de>, linux-kernel@...r.kernel.org,
	akpm@...l.org
Subject: Re: [PATCH] Fix /sys/device/.../power/state regression

On Friday 26 January 2007 5:19 pm, Matthew Garrett wrote:
> On Fri, Jan 26, 2007 at 04:42:56PM -0800, David Brownell wrote:
> > On Friday 26 January 2007 3:15 pm, Matthew Garrett wrote:
> > > It's certainly the case that fixing those drivers would result in a 
> > > better long-term situation - however, nobody currently seems to have any 
> > > interest in doing so...
> > 
> > And the way these things work, unfortunately, is that merging your patch
> > would ensure nobody ever gets such interest.  Removing that "state" file
> > (and its bogus infrastructure) has already taken a few years too long.
> 
> I'd argue that the onus is on those who wish to remove the interface to 
> ensure that equivalent functionality exists first.

Are you now arguing that "rmmod $DRIVER" doesn't suffice for what you
were wanting to do?  If so, why?  What's the delta in power usage?


> Now this is what throws me somewhat. Last May, you argued strongly in 
> favour of keeping the interface:
> 
> "Which IMO makes removing this a Bad Thing.  It needs to have some
> kind of replacement in place before the "magic numbers" go away."
> 
> (http://lists.osdl.org/pipermail/linux-pm/2006-May/002376.html)

Specifically to support driver testing.  Recall that such testing was
at that time the only known quasi-viable use of that interface.  (And
despite your pushback, it still seems that way to me...)

I've changed my mind about that; it's just as easy to whip up custom test
logic, and in any case the stuff that I most needed to test (wakeup
events) can't be tested like that.  Bad testing infrastructure doesn't
really do anyone favors, anyway; too much time spent with workarounds,
many of which cover up the bugs you're trying to uncover by testing.

- Dave

-
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