Hi David.
>>>> Basically, we need to guarantee that on resume, all CURRENTLY
>>>> PLUGGED IN hardware gets initialised to a known state, and anything
>>>> short of that is just plain buggy. This includes the case where on
>>>> resume, devices are found plugged into different ports than on
>>>> suspend.
>>> If you assume a Linux-USB system that's fully set up with the
>>> hotplugging tools, what functionality is missing?
>> The words "If you assume" in the above state the problem quite
>> clearly. No such assumption can be made, and when you take that
>> assumption out of the equation, the above required guarantee falls
>> straight in your lap.
> That is, if you don't use the tools, they won't solve your problems.
How is that comment related to mine? I don't see the connection between
them? That is, unless you're deliberately ignoring the rest of the
comments I made in the email you replied to?
Let me reiterate my point, which everybody other than you apparently
agrees with:
At the point in the resume cycle where we first become able
to run user-mode stuff, we need to known the EXACT CURRENT
STATE of EVERY piece of hardware that is plugged into the
system.
There's no science fiction in there, despite your attempts to prove
otherwise. If you wish to claim that we have to be able to restore every
piece of hardware to its state last time it was plugged into the system,
that's your prerogative, but it's not related to the point I was making,
and it's also not related to any belief I'm likely to entertain.
> At that point, why are you complaining? The first issue is that
> you're not using the tools ... not that the problems aren't already
> solved. "Falls straight in your lap" is in this case an issue of not
> using the tools provided to solve this problem.
What tools? I don't see any that are even relevant to the discussion, as
we're talking about what happens before we're able to consider running
userland applications.
> On the other hand, if you answered my question by showing where some
> particular functionality is missing, that'd be a start. It's known
> as providing a bug report.
If you'd cared to explain to me why the problem I reported previously
occurred, rather than saying "it's not possible, so it didn't happen"
in the way you did, then I might just have some respect for your
comments. So far, I don't.
As it happens, I've now received an explanation of what was going wrong
(it's a known APM problem not related to USB) from somebody willing to
talk reality, and the issue is now solved. You can thus safely refrain
from spouting any more rubbish my way.
> Even better would be to provide simple patches that'll resolve the
> issue of any missing functionality, in a way that they can easily be
> merged into the ongoing work (2.4.current for now, and common
> distros).
I leave that to people who actually understand the hardware they're
dealing with, and whilst I understand most of the PC's hardware, USB is
definitely not yet included.
> (And yes, this thread is completely offtopic, hasn't been related to
> firmware for ages, and more belongs on the linux-hotplug list...)
{Shrug} Your opinion, not anyone else's, if the comments I've received
are any guide.
Best wishes from Riley.
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
