Hi! > | > Yes, we may just not close a sound device file, but phone > | > applications I've seen, do close the file. > | > | Fix the app, then. > --- > > I would normally call designs that expect important functions (like > power on/power off) to happen as side effects of other operations (like > opening and closing files) broken to begin with. It's still a bad idea > to hide policy inside the driver. Then you are welcome to go design your own operating system. I certinaly do not want open() on powered down /dev/dsp to succeed with /dev/dsp powered down. > There's nothing contrived or corner-case-ish about cyclic operations in > a world where media players, animations, etc., are utterly > commonplace. Yep? And you close your sound device between those? > And latency may be ignorable in a laptop environment, but it absolutely > isn't in embedded devices, which users expect to operate immediately, as > though they were gear-driven rather than computer-driven. What latency are you talking about? Powering up piece of hw takes one milisecond or something. If your /dev/dsp takes 3 seconds to power up, you probably need userspace policy daemon. But that is not the case, hw takes few miliseconds to wake up. Pavel thinking about "don't feed the Trolls" label -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
