linux-kernel - Re: Changes to sysfs PM layer break userspace

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]

Date:	Tue, 19 Dec 2006 22:57:29 +0000
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	David Brownell <david-b@...bell.net>
Cc:	linux-kernel@...r.kernel.org, gregkh@...e.de
Subject: Re: Changes to sysfs PM layer break userspace

On Tue, Dec 19, 2006 at 01:22:12PM -0800, David Brownell wrote:

> Stop trying to use broken and deprecated APIs; and realize that "previously
> working" meant you just hadn't tripped over the serious bugs yet.

I'm happy to stop using broken and deprecated APIs, providing that 
there's *actually a replacement*.

> Drivers can and should know how to do that sort of stuff themselves,
> so the power savings are reliable and consistent no matter what user
> space tools are (or aren't) used.

To the extent that that's possible, I entirely agree - however, it 
clearly isn't always. Not all hardware can be powered down without 
losing functionality, and so in those cases it's important that there be 
a mechanism to allow that decision to be made by userspace.

> Drivers know how to get power savings a lot better than any userspace
> code ever could ... with the exception of hints like "ifdown eth0"
> letting the driver know that right now is a good time to power down
> almost everything, since it's not going to be used until "ifup".

But in the cases where you don't have fine grained power management in 
the hardware, it's still desirable to be able to suspend an unused 
network agent. The driver can't do it by default, because that would 
break existing behaviour.

> As a generic mechanism, that interface has *ALWAYS* been "broken
> by design"; I'd call it unfixable.  It's deprecated, and scheduled
> to vanish; see Documentation/feature-removal-schedule.txt ...

The fact that something is scheduled to be removed in July 2007 does 
*not* mean it's acceptable to break it in 2006. We need to find a way to 
fix this functionality in the meantime.

-- 
Matthew Garrett | mjg59@...f.ucam.org
-
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/