Message-Id: <200708030929.17049.david-b@pacbell.net>
Date:	Fri, 3 Aug 2007 09:29:16 -0700
From:	David Brownell <david-b@...bell.net>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	linux-usb-devel@...ts.sourceforge.net, Greg KH <gregkh@...e.de>,
	Rogan Dawes <lists@...es.za.net>,
	Oliver Neukum <oliver@...kum.org>,
	linux-kernel@...r.kernel.org,
	Alan Stern <stern@...land.harvard.edu>
Subject: Re: [linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes

On Friday 03 August 2007, Matthew Garrett wrote:
> On Fri, Aug 03, 2007 at 07:37:55AM -0700, David Brownell wrote:
> > On Friday 03 August 2007, Matthew Garrett wrote:
> > > Popping up a box saying "Is your device broken?" isn't good UI. 
> > 
> > Which is why I didn't suggest doing that, of course.  The only
> > one making that kind of straw man argument seems to be you.
> 
> But however you phrase it, that's effectively what it is.

As http://en.wikipedia.org/wiki/Straw_Man phrases it,
"A straw man argument is an informal fallacy based on
misrepresentation of an opponent's position ... the
opponent's actual argument has not been refuted."

That's clearly what you've been doing by proposing some
specific -- and obviously bad -- user interfaces, none
of which have the fundamental characteristic I described.


> And, frankly, if I got a requestor like that every time I plugged in a 
> new USB device I'd be fairly unhappy.

Which is why my comment was about something else entirely!

That is, having an out-of-kernel database which could preclude
the need for such requestors for devices already known.


> > If I were to describe any dialog users would see, it would be more
> > like "I don't recognize this device, help me set it up right...".
> > As with music CDs, that help might update the database for the next
> > person.  (Assuming this were done well, of course.)
> 
> Users understand CDs. They don't understand runtime power management.

A new straw man!  Because power management isn't the relevant point.

All they'd ever have to understand is:  is it working correctly right
now?  That's after an experimental autosuspend, and after poking the
hardware to verify that, from the kernel perspective, it acts OK.

Oliver pointed out that the typical failure mode is easily detected
in software.  So when the user says "OK, I'll help set it up", the
worst case would be that the device is NOT recorded already in that
database, the user might need to be ready to unplug then replug the
device (when that experiment fails).


> > Speaking of which, what's this /dev/bus/usb/* crap on Ubuntu?
> > I had to undo all that on my Feisty system before any normal
> > /proc/bus/usb stuff would work again.
> 
> "Usbfs files can't handle Access Control Lists (ACL), which are the 
> default way to grant access to USB devices for untrusted users of a 
> desktop system. The usbfs functionality is replaced by real device-nodes 
> managed by udev. These nodes live in /dev/bus/usb and are used by 
> libusb."
> 
> (From Kconfig)

That's shortly after the explanation that the relevant Kconfig
option is for  ** /proc/bus/usb ** files ... note that despite the
strangeness in that text (usbfs still hasn't been "replaced", so
that should say "will eventually be replaced" not "is replaced"),
it's clear that /proc/bus/usb/ and /dev/bus/usb/ are two different
things.  And thus:  that Ubuntu's /dev/bus/usb/ setup is flakey.


> > > You commonly run a laptop off battery while having a printer plugged in?
> > 
> > Unfortunately I need to run laptop off AC since its battery life is
> > painfully short, and since Linux behaves so incredibly rudely when
> > the battery power goes down to almost-zero:  it lets it go to zero
> > rather than hibernating.  (And doesn't automatically enter suspend
> > when it idles, either...)
> 
> System/Preferences/Power Management

There's no option there to affect what happens when it's running
on battery power.  Though I'm curious what it means when it has
a "suspend" option (not "hibernate") ... I wouldn't mind STR.


> > Note by the way that if you were -- for the sake of argument -- accept
> > my premise that this should all be handled in userspace ... it's very
> > easy to make userspace code do what you want.  It doesn't need to be
> > done inside the kernel.
> 
> It can be, but I'd prefer to have userspace enable functionality than 
> have the kernel break things.

That side of things has been absent from the discussion so far.

When something is wrongly blacklisted (by whatever), how are you
proposing that it get un-blacklisted?  Seems to me that whatever
mechanism resolves that issue should also work the other way around...

- Dave

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

Powered by blists - more mailing lists