Hi! > >Here's one approach: use a syscall (e.g., ioctl) saying "block until > >there's new data on this fd, or N milliseconds have passed, whichever > >is *later*". This way each client declares the update rate it wants > >and can change it on the fly. The driver sees all the requests and can > >perform the minimum hardware quering -- for example, it won't query > >the hardware at all if no client has submitted a request with > >parameter N more than N milliseconds go. And there's no excessive work > >or interrupts. Some (simple) kernel code infrastructure is needed to > >help drivers manage the pending requests. > > Here's a rough sketch for the userspace side of a continuous function > sampling interface. It handles the blocking a bit better than the > above proposal, in that it lets you easily handle multiple readouts. > It's agnostic about /dev vs. /sys. Looks good to me. > I'm not getting into the kernel side for now; it's doable, and with > proper infrastructure (e.g., at the sysfs level) can be elegant and > efficient. I guess that hwmon people would like this, anyway... Are there any plans at merging tp_smapi, BTW? After fixing few minor details (like removing " mV" from files)... it looks like it would fit into hwmon infrastructure rather nicely. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
