From: Adrian Bunk <bunk@kernel.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg KH <gregkh@suse.de>, Linus Torvalds <torvalds@osdl.org>,
Andrew Morton <akpm@osdl.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: Thu, 13 Sep 2007 22:19:10 +0200 [thread overview]
Message-ID: <20070913201910.GH3563@stusta.de> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0709131154240.7406-100000@iolanthe.rowland.org>
On Thu, Sep 13, 2007 at 12:07:15PM -0400, Alan Stern wrote:
> On Thu, 13 Sep 2007, Adrian Bunk wrote:
>
> > > > It is a good thing if userspace can add currently missing devices to
> > > > whitelists, but the whitelist itself should be in the kernel.
> > >
> > > It's not clear that this sort of approach will turn out to be workable.
> > > Whitelists/blacklists do okay in the kernel when they refer to a
> > > relatively small subset of devices. However in this case I have the
> > > impression that we're talking about roughly a 50/50 split. Keeping an
> > > in-kernel list with even 10% of all existing USB devices simply isn't
> > > feasible.
> >
> > What about this is not feasible?
> >
> > The amount of work for maintaining the list is the same:
> >
> > No matter whether it's in-kernel or in the userspace, you need a list of
> > working devices in some machine readable format.
> >
> > Whether this gets used by the kernel, by userspace, or both, shouldn't
> > make any difference.
> >
> > Kernel image size can be a problem in some cases, but an in-kernel list
> > doesn't have to be mandatory but could be made selectable in kconfig.
>
> Well, size is one problem I had in mind. There are a _lot_ of USB
> devices in existence.
Kernel image size matters much for some uses, but not for all.
> But mainly it's a question of maintenance and modification. Kernel
> developers don't really enjoy maintaining black- or whitelists of
> devices, together with all the work involved in sorting through the
> issues when somebody posts an email saying "My device doesn't work!".
>
> Also, modifying device lists in the kernel tends to be a slow process,
> involving at least one kernel release cycle. It's much easier for
> people to maintain userspace databases. Now I realize you proposed
> there be a userspace interface for modifying the kernel's whitelist --
> but if you're going to do that, why not put the entire whitelist in
> userspace to begin with?
No matter whether the list is in userspace or in the kernel, maintaining
it is exactly the same job of adding entries into some machine readable
list (no matter whether it's a C struct or a CSV list that later gets
converted).
This could be the kernel developers or some external sf project that
gets synced with the kernel during each merge window.
> Maybe you're concerned about propagating updates as painlessly as
> possible -- if the whitelist is in the kernel then every kernel release
> would include an update. But in userspace it's possible to do updates
> even more quickly and painlessly. For example, there could be a
> network server available for both interactive lookups and automatic
> queries from HAL.
>...
No, what I'm concerned about is that this would require userspace for
something that is completely in-kernel.
> Alan Stern
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 20:19 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 [this message]
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
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=20070913201910.GH3563@stusta.de \
--to=bunk@kernel.org \
--cc=akpm@osdl.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@osdl.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