linux-kernel - Re: [GIT PATCH] USB autosuspend fixes for 2.6.23-rc6

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: <Pine.LNX.4.44L0.0709141015550.3782-100000@iolanthe.rowland.org>
Date:	Fri, 14 Sep 2007 10:26:25 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Adrian Bunk <bunk@...nel.org>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg KH <gregkh@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	<linux-kernel@...r.kernel.org>,
	<linux-usb-devel@...ts.sourceforge.net>,
	Oliver Neukum <oneukum@...e.de>
Subject: Re: [GIT PATCH] USB autosuspend fixes for 2.6.23-rc6

On Thu, 13 Sep 2007, Adrian Bunk wrote:

> What is not policy is the blacklist or whitelist information.

That's debatable, but never mind.

> And I'm also a bit concerned why "is policy" is that much a reason 
> against setting *reasonable default policies* without requiring the user 
> to do various things in userspace.

"Don't autosuspend" _is_ a reasonable default policy.  It's what Linux 
has been doing all along.

> Especially since this creates some nasty interdependencies between the 
> kernel and userspace.

No it doesn't.  If the kernel fails to provide the mechanism there's 
nothing that userspace can do about it anyway.  If the kernel does 
provide the mechanism and userspace ignores it, then things continue to 
work the same as they always have.

> And as an example, couldn't you equally say it's wrong that the kernel
> enables DMA on disks instead of leaving it to userspace?

It's not analogous.  Autosuspend involves setting an idle-delay time, 
which depends on the type of device and how it is being used.  DMA 
doesn't involve anything like that.

But forget about the delay for the moment.  If there were a high 
percentage of disk drives which would fail when DMA was enabled, then 
yes, the decision should be left to userspace.  If the percentage is 
low enough (and shrinking as vendors become more clueful) then moving
the decision into the kernel is acceptable.  At the moment USB 
autosuspend is not in this position, as we have learned painfully.

> We've already seen the udev disaster where upgrading from Debian 3.1 to 
> Debian 4.0 means upgrading from kernel 2.6.8 to 2.6.18 with the udev 
> version in Debian 3.1 not supporting kernel 2.6.18 and the udev version 
> in Debian 4.0 not supporting kernel 2.6.8, and I don't have a good 
> feeling about outsourcing more and more things to userspace tools not 
> distributed with the kernel.

This isn't a question of not being able to boot, like the udev fiasco;
this is a question of saving a few watts of power.  While it may be 
important for laptop users, it is not critical.

Alan Stern

-
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/