~laptop-mode-tools-dev/laptop-mode-tools/main : changes

~laptop-mode-tools-dev/laptop-mode-tools/main » Changes from revision 275

From Revision 264 to 245

Rev	Summary	Authors	Tags	Date
264	Support execution of complex commands Support execution of complex commands Thanks to Changaco for the patch. It seems that the exec-commands module cannot execute "complex" commands, for example containing an output redirection ">". I'm sending you a patch that fixes this for me. I was trying to see if I could use exec-commands to shut down the second core of my CPU with "echo 0 > /sys/devices/system/cpu/cpu1/online". Do you think that is useful ?	Ritesh Raj Saarraf		12 years ago
263	check kernel's native suspned functionality check kernel's native suspned functionality	Ritesh Raj Saarraf		13 years ago
262	use in-kernel block dev polling use in-kernel block dev polling	Ritesh Raj Saarraf		13 years ago
261	Initialize the PATH variable within us. This helps when our ... Initialize the PATH variable within us. This helps when our caller did not have a proper environment	Ritesh Raj Saarraf		13 years ago
260	Explain about the locks. Explain about the locks. We have the two locks approach because: * lmt can take upto 10 seconds to execute. * udev can generate many events at one time Descriptor 8 is to see the first lock. This lock just checks if I can consider executing lmt. So, descriptor 8 (LMT_REQ_LOCK) gets acquired successfully. Then it releases and acquires LMT_INVOC_LOCK && executes lmt_main(). This is important. While lmt_main() is executing (which can be around 8 seconds), we still want a queue of 1 item from udev events. So while first invocation acquired LMT_INVOC_LOCK and is running (for 8 seconds), 2nd invocation acquired LMT_REQ_LOCK and then tried to acquire LMT_INVOC_LOCK. But it could not acquire LMT_INVOC_LOCK. So it went into retry() where it again acquired LMT_REQ_LOCK, never released it, tried acquired LMT_INVOC_LOCK, failed and kept iterating for 10 times before giving up. Since Invocation 1 was in runtime and Invocation 2 was in queue, we wouldn't care about further invocations in that 10 second iteration window. They get out because they can't acquire the lock, LMT_REQ_LOCK in the very first check itself.	Ritesh Raj Saarraf		13 years ago
259	drop count variable and log with proper msg type drop count variable and log with proper msg type	Ritesh Raj Saarraf		13 years ago
258	prepare 1.57 release prepare 1.57 release	Ritesh Raj Saarraf	1.57	13 years ago
257	use THIS_CPU_GOVERNOR as the governor use THIS_CPU_GOVERNOR as the governor	Ritesh Raj Saarraf		13 years ago
256	pass arg to the calling function pass arg to the calling function On Fri, 18 Feb 2011 17:45:18 +0530 Ritesh Raj Sarraf <rrs@researchut.com> wrote: > > Can you elaborate what you mean by "discards all the arguments given > > to it" ? > > How are you calling lmt? I'm talking about /usr/sbin/laptop_mode file, which is a shell script. Man page says that is should accept "auto" and "status" as a command and an optional "force" argument. I've looked through this script and have found out that it ignores any arguments it gets. It tries to read positional parameters in function called "lmt_main_function", but what it reads are the parameters of function, not of the script. And as the script doesn't pass its parameters to this function, they are effectively ignored. My patch changes this, so that arguments are recognized. I hope this explains the issue sufficiently.	Ritesh Raj Saarraf		13 years ago
255	prepare release 1.56 prepare release 1.56	Ritesh Raj Saarraf	1.56	13 years ago
254	install udev rule install udev rule	Ritesh Raj Saarraf		13 years ago
253	udev rule to trap kernel events udev rule to trap kernel events	Ritesh Raj Saarraf		13 years ago
252	verbose msg for lock retry verbose msg for lock retry	Ritesh Raj Saarraf		13 years ago
251	add locking support using flock add locking support using flock	Ritesh Raj Saarraf		13 years ago
250	revert previous lock approach revert previous lock approach	Ritesh Raj Saarraf		13 years ago
249	check for lock inside laptop_mode also check for lock inside laptop_mode also	Ritesh Raj Saarraf		13 years ago
248	better version with lock invocation better version with lock invocation	Ritesh Raj Saarraf		13 years ago
247	Add generic hotplug event support Add generic hotplug event support	Ritesh Raj Saarraf		13 years ago
246	Add initial basic support for hotplug events Add initial basic support for hotplug events Currently, laptop-mode-tools only runs on AC plug in and plug out. However, we want to have it run when USB devices are attached. This patch allows us to efficiently run laptop_mode on only the new devices. There are three changes: 1. laptop_mode can now take two new command line parameters, modules=<list of modules> and devices=<list of devices>. The modules list is intended to limit laptop_mode to running only the given module scripts. For example, laptop_mode modules="usb-autosuspend lcd-brightness" will only run those two scripts and nothing else. If no modules list is given, all modules will be run (pre-patch behavior). The devices parameter list is intended to limit the module scripts to running over only the listed devices. For example, laptop_mode devices="1-1 1-2" will provide the list as a variable $DEVICES to all module scripts. The module scripts that support the list are to run nothing but the listed devices. If they don't run those devices in the first place, it still has the effect of masking out all the other devices. However, it is not meant to be used this way; the devices list should be used in conjunction with the modules parameter, and be passed only to the module(s) that support those devices. For example, "1-1 and 1-2" are usb devices and should only be used alongside a modules list of usb scripts, like usb-autosuspend. 2. In this patch, the only module script that has been changed to use the device list is usb-autosuspend. In the future, other modules can be modified to use the device list as well. However, they should follow the same usage described in #1 -- run over only the listed devices, but do not run on any device that would not otherwise be run; and if no device list is given, run just like before. The device list is basically a mask rather than an imperative list. ("Do not run for any device that is not listed", rather than "must run for all these devices.") Example: suppose there are two modules, foo and bar. foo runs over devices foo-0, foo-1, foo-2, and bar-0. bar runs over bar-0, bar-1, bar-2, and foo-0. If we pass in devices="foo-0 foo-1 foo-2 bar-0", foo will run all 4 devices, but bar will only run bar-0 and foo-0. It will NOT be forced to run over foo-1 and foo-2 because it doesn't support them. To summarize, this patch retains backward compatibility. If the modules param is not specified, it runs all modules. If a module script is not given a device list, it should run over the entire set of devices that it operates on. 3. Added a udev rule that uses laptop_mode to invoke only usb-autosuspend for only a limited set of device(s), when it detects new usb devices. This is so usb-autosuspend can give new usb devices the correct setting. However, this patch does not provide for installing this rule file. It is up to build/integration scripts to pick out the rule file and install it.	Ritesh Raj Saarraf		13 years ago
245	wrong check for missing string wrong check for missing string	Ritesh Raj Saarraf		13 years ago

Older »