From: Adrian Bunk <bunk@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alan Stern <stern@rowland.harvard.edu>, Greg KH <gregkh@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org,
linux-usb-devel@lists.sourceforge.net,
Oliver Neukum <oneukum@suse.de>
Subject: Re: [GIT PATCH] USB autosuspend fixes for 2.6.23-rc6
Date: Fri, 14 Sep 2007 00:05:43 +0200 [thread overview]
Message-ID: <20070913220543.GJ3563@stusta.de> (raw)
In-Reply-To: <20070913212842.GI3563@stusta.de>
On Thu, Sep 13, 2007 at 11:28:42PM +0200, Adrian Bunk wrote:
> 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.
Let me paraphrase the latter:
Given a distribution shipping with kernel 2.6.23 released in 2007.
What is the maximum amount of userspace I might have to upgrade
if I'll want to use kernel 2.6.43 released in 2011 (sic) with this
distribution?
E.g. when looking at the reverse dependencies of libhal, it would not be
funny if kernel 2.6.43 required a more recent version of HAL.
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
next prev parent reply other threads:[~2007-09-13 22:05 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-13 13:33 [GIT PATCH] USB autosuspend fixes for 2.6.23-rc6 Greg KH
2007-09-13 14:52 ` Adrian Bunk
2007-09-13 15:20 ` Alan Stern
2007-09-13 15:40 ` Adrian Bunk
2007-09-13 16:07 ` Alan Stern
2007-09-13 16:34 ` Greg KH
2007-09-13 16:43 ` Linus Torvalds
2007-09-13 19:13 ` Alan Stern
2007-09-14 0:24 ` Matthew Dharm
2007-09-14 14:34 ` Alan Stern
2007-09-14 8:55 ` Jiri Kosina
2007-09-14 9:59 ` Greg KH
2007-09-13 19:26 ` Pete Zaitcev
2007-09-13 20:19 ` Adrian Bunk
2007-09-13 20:31 ` Alan Stern
2007-09-13 20:44 ` Linus Torvalds
2007-09-13 21:28 ` Adrian Bunk
2007-09-13 22:05 ` Adrian Bunk [this message]
2007-09-14 0:11 ` Linus Torvalds
2007-09-14 13:21 ` Mark Lord
2007-09-14 14:15 ` Adrian Bunk
2007-09-14 14:29 ` Alan Stern
2007-09-14 14:26 ` Alan Stern
-- strict thread matches above, loose matches on Subject: below --
2007-09-17 12:56 Hans de Goede
2007-09-18 10:39 Joerg Schilling
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070913220543.GJ3563@stusta.de \
--to=bunk@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=oneukum@suse.de \
--cc=stern@rowland.harvard.edu \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox