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. Note that I said KNOWN STATE in the above. This does not require that we restore any previous state, only that when we get to the stage where userland can be used, we know the precice state of all currently plugged in hardware. Have a look at the Linux sound subsystem (where this guarantee is needed as well, but isn't currently provided) and the mess that has resulted from that - not least the fact that with several of the sound drivers, one has to reboot the computer several times to get the configuration right as many of the wrong configurations just lock Linux up solid. > I'd expect that most of that functionality falls into the category > of "configuring devices after they exist", which Unix (and hence > Linux) has traditionally deferred to some knowledgeable sysadmin. > Not that such a sysadmin is usually around ... hence the need for > more intelligence! But less in the kernel, and more in userspace. What we need most is to turn Linux PnP from the current "plug and pRay" to the ideal "plug and pLay", and the guarantee stated at the top is a prerequisite for that. Best wishes from Riley. _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
