On Wed, 2011-09-07 at 15:37 +0200, David Henningsson wrote: [...] > I've tried to talk to a few people, and from what I can tell, there is > no point in time when the system can be considered to be fully "up and > running". This means e g, if a new bluetooth device shows up say 30 > seconds after PulseAudio starts, we don't know if this was because > someone actually connected the bluetooth headset at that point, or if it > was connected from start but took 30 seconds to respond and negotiate > with the bluez stack. Same goes for USB, and in theory other devices as > well, but I've never seen it happen in practice to anything internal/PCI. > > Also, this applies not only at boot, but also at resume from suspend or > hibernate. > > Given that lack of information from the kernel/hardware, I can only > assume that order-based handling is bound to fail. And so is > module-switch-on-connect, that implements this. (And so is Ubuntu's > suspend/resume script, btw.) > > This leaves us rule/priority-based policy d ecisions, which I believe is > what Colin thinks as well. Comments? IMO, this approach to device plugging is a bit of a cop-out. Maybe a device appearing 10 seconds after boot/resume is not hot-plugged, but a device that appears >2 minutes almost certainly is. So I think with heuristics, we can deal with this. For example, we call the system booted when there are no new events for X seconds (the value of X can be the subject of much bikeshedding), we call the system booted/resumed. I'm not involved in the bits of the stack that do this, so feel free to point out if I'm missing something. -- Arun
