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: <20070913212842.GI3563@stusta.de>
Date:	Thu, 13 Sep 2007 23:28:42 +0200
From:	Adrian Bunk <bunk@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Alan Stern <stern@...land.harvard.edu>, 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, Sep 13, 2007 at 01:44:23PM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 13 Sep 2007, Adrian Bunk wrote:
> > 
> > No, what I'm concerned about is that this would require userspace for 
> > something that is completely in-kernel.
> 
> If done right (and autosuspend now is), there is no "required" userspace.
> 
> If you want autosuspend, you just say so. The kernel doesn't do it by 
> default. This is not about "user space required" - it's about "user space 
> can ask for it if it wants to".
> 
> Notice? There doesn't even have to be any blacklists/whitelists at all. It 
> really can be just an application that allows the user to check or uncheck 
> the capability (with a warning saying something like: "Some USB devices 
> may disconnect when suspended - if this affects you, uncheck this").
> 
> That's why the kernel shouldn't set policy. It's a *good* thing to just 
> expose the capabilities, but not necessarily use them! 

What is not policy is the blacklist or whitelist information.

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.

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

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?

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.

> 		Linus

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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