On Fri, Aug 03, 2007 at 09:29:16AM -0700, David Brownell wrote:
> On Friday 03 August 2007, Matthew Garrett wrote:
> > 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.
Plus a mechanism for pushing data into it, plus a mechanism for ensuring
that inaccurate data doesn't get in there, plus some what of pushing
updates out to users, plus privilege escalation for setting the value,
plus policy management to ensure that normal users can't mess with the
autosuspend values for other users? No, this isn't trivial - especially
when there's a straightforward in-kernel mechanism (only enable it when
it's known to be safe)
> > "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.
Both /proc/bus/usb and /dev/bus/usb are provided. Anything that fails to
work with /dev/bus/usb is buggy - libusb copes fine. We're in the
process of transitioning away from the legacy interface. It could be
worse - we could have just removed it on the grounds that it doesn't
work properly.
> > 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.
That's odd. In the "On battery power" tab I see an option to choose the
action when the battery power is critically low.
> > 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...
The worst case scenario in the "Disable by default, allow userspace to
whitelist" case is that some machines draw slightly more power. The
worst case scenario in the "Enable by default, allow userspace to
blacklist" case is that some hardware doesn't work because of race
conditions between autosuspend and userspace having the opportunity to
disable it, or devices not being in the blacklist, or somebody not
having adequately new usrspace, or...
--
Matthew Garrett | [email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
