> Why not just accept that "some form of" doesn't involve USB suspend?
>
> Your "some form of..." adds memory to USB, but it's a curiously
> selective sort. If I unplug a disk drive and plug it into another
> port, why shouldn't that "just work"? After all, the same mechanism
> that somehow deduces "same disk" (how, given that serial numbers are
> known not to work?) on one port could as easily apply it to another
> port. If it shouldn't work that way, why should it work if it's
> unplugged from one port and plugged back into the same port? (Which
> is exactly what you're arguing, by saying power fail "must not" matter.)
> And if it should, why shouldn't it work even outside the scope of that
> particular swsusp state memory? (Unplug today, replug tomorrow, and
> no system suspend/powerdown in between.) Both cases are simple variants
> of the case Linux vetoed kernel support for some time ago.
Good questions.
The kernel implements ACPI. That requires that the suspended system
restore state even if power was lost due to power management.
So anything that does not result from power management can be ignored :-)
I would choose the simplest implementation that is consistent with these
requirements. That would IMHO be the same devices plugged into the same
ports. Anything else is user getting what he asked for.
I can understand why you want to treat power loss not as a suspend state.
It leads to hairy questions. However I regard ACPI more important than USB
in questions of power management. As far as I have used words like "must"
these are what I regarded as inescapable conclusions from these standards.
I did not intended to imply that I define what USB should do. I kindly ask
you to believe me that when you understand me as implying that I was
arguing what I regarded as logical conclusions from requirements in the
specs I considered relevant in the area. Please accept my apologies. Your
views on USB and the kernel in general certainly deserve as much regard
as mine. If my mails were lacking in tact and tone I am sorry for that too.
The current implementation of power management is elegant and simple.
I would never doubt that. However I still believe it flawed, because IMHO
it does not implement features the power management specs of ACPI
require. Not only doesn't it meet the features I can see no way to meet them
and retain the basic design that power off is not a suspend state. It is
true that I fully believe these requirements are very sensible and are
what makes having a laptop really cool. Thus my more than usual emotional
interest in that area. But please believe that I will explicitely say when
I only want a feature as opposed to conclude its necessity from a technical
viewpoint or the specs. It is entirely possible that emotions have clouded
my judgement in this issue. If so, I am sorry about it.
Regards
Oliver
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
