On Thu, 13 Sep 2007, Adrian Bunk wrote:
> What is not policy is the blacklist or whitelist information.
That's debatable, but never mind.
> 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.
"Don't autosuspend" _is_ a reasonable default policy. It's what Linux
has been doing all along.
> Especially since this creates some nasty interdependencies between the
> kernel and userspace.
No it doesn't. If the kernel fails to provide the mechanism there's
nothing that userspace can do about it anyway. If the kernel does
provide the mechanism and userspace ignores it, then things continue to
work the same as they always have.
> 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?
It's not analogous. Autosuspend involves setting an idle-delay time,
which depends on the type of device and how it is being used. DMA
doesn't involve anything like that.
But forget about the delay for the moment. If there were a high
percentage of disk drives which would fail when DMA was enabled, then
yes, the decision should be left to userspace. If the percentage is
low enough (and shrinking as vendors become more clueful) then moving
the decision into the kernel is acceptable. At the moment USB
autosuspend is not in this position, as we have learned painfully.
> 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.
This isn't a question of not being able to boot, like the udev fiasco;
this is a question of saving a few watts of power. While it may be
important for laptop users, it is not critical.
Alan Stern
-
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]
