On Tue, 21 Nov 2006, Shem Multinymous wrote: > You may want to report your experience on the git@vger list, there is > some talk now of fixing stuff and quality input from new users can be > very useful. I will see if I can compose a proper email for git@vger, then. > >Shem, it includes the T43 ec-bug-fix you don't like, as it worked better > >here with userspace than the more correct fix. > > Err, which one and why didn't I like it? So many patches... The fix for the initial unknown status of the fan in T43 and friends. I'm using the "report it as auto" patch, and not the "report it as unknown" patch. > > 3. Add rate control to procfs and any sysfs APIs, to avoid local > > DoS. Read fan speed once every 5s, read temperatures once every 2s. > > I don't think this is right to have driver-specific code for this. > It's an issue shared by many drivers, so ad-hoc solutions are the > wrong way to go about it; see the recent threads about battery and > hdaps monitoring. For now, just trust the user; there are so many > other ways to DoS a Linux system isn't not even funny. But you are DoSing the *EC* in this case, not the kernel. It is the same problem with direct access to LPC3B like I observed when playing with tp_smapi: you do it too much, the EC goes weird and the ThinkPad may do something stupid, like overcharging a Li-ion cell (This is sort of an unlikely nightmare scenario, granted. Usually the user will notice the machine is hung *hard* before it could ever happen). The fact that ACPI is heavyweight helps a bit, but in a fast processor, it can drive the poor EC nuts just fine. Shouldn't drivers protect the hardware against such DoSing (unlike the kernel)? > >The TODO feature lists is: > > 2. Add kernel-space fan control override > > What do you mean? tp-fancontrol in kernel land, but with an ACPI-like interface. As if Lenovo/IBM had done things properly and given us 8-12 thermal zones with trip points and a system fan power resource in all of them. > >to pull or clone them. I don't know how well stgit branches play with > >remote repos, as it has extra metadata. > > I don't think the StGIT metadata will survive a push or fetch (but > please do ask Catalin on git@vger). I think your options are: I don't think they will do, either. They survive rsync, but rsync ain't available at repo.or.cz. > 1. Just push --force the tip of your StGIT stack, and tell people to use > +ref. This would work, yes. > 2. Push the tip of your StGIT stack, using a new branch every > time.This is essentially what's done with the -mm tree. This will cause a lot of cruft in repo.or.cz that I can't easily fix (I can't tell the git dumb push protocol to delete a remote branch. Heck, the thing is so dumb it can't even figure out it doesn't need to push something, unlike the pull protocol...). I may not mind it much on the repo itself, but I don't want to look at a list of 2000 heads :) stgit at least hides it well (it creates a different root tree for every patch...) > 3. Linearly append patches, instead of fixing earlier ones. Not good. It is unsuitable for submission upstream, so it would disturb my workflow. > 4. Apply git on top of a quilt tree. This one shows promisse, but quilt->git conversion is not nearly as nice as using stgit, and it requires special care (and a separate clean branch that only gets collapsed merges or gets "patch and commit" merges instead of git merges) to keep story sane. > Again, this is worth bringing up in git@vger. I will try to come with a proper mail to git@vger, then. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
