Dist and install udev rule.

2005-12-20  Kristian Høgsberg  <krh@redhat.com>

        * Makefile.am: Dist and install udev rule.

        * collector.c: (open_fd):
        * sysprof-text.c: (no_module):
        * sysprof.c: (on_start_toggled): Update device filename.

        * 60-sysprof.rules: New udev rule file to set permissions for
        sysprof char device.

        * module/sysprof-module.c: Switch kernel module to use a misc char
        device instead.  Start and stop the timer on device open and
        close instead of module load and unload.
This commit is contained in:
Kristian Høgsberg
2005-12-20 17:55:03 +00:00
committed by Kristian Høgsberg
parent c1f411c356
commit ad5ffd749b
9 changed files with 94 additions and 46 deletions

30
TODO
View File

@ -150,21 +150,6 @@ Before 1.2:
Maybe get_user_pages() is the way forward at least for some stuff.
* Correctness
- When the module is unloaded, kill all processes blocking in read
- or block unloading until all processes have exited
Unfortunately this is basically impossible to do with a /proc
file (no open() notification). So, for 1.0 this will have to be
a dont-do-that-then. For 1.2, we should do it with a sysfs and
kobject instead.
- When the module is unloaded, can we somehow *guarantee* that no
kernel thread is active? Doesn't look like it; however we can
get close by decreasing a ref count just before returning
from the module. (There may still be return instructions etc.
that will get run). This may not be an issue with the timer
based scanning we are using currently.
- See if there is a way to make it distcheck
- grep FIXME - not10
@ -432,6 +417,21 @@ Later:
DONE:
* Correctness
- When the module is unloaded, kill all processes blocking in read
- or block unloading until all processes have exited
Unfortunately this is basically impossible to do with a /proc
file (no open() notification). So, for 1.0 this will have to be
a dont-do-that-then. For 1.2, we should do it with a sysfs and
kobject instead.
- When the module is unloaded, can we somehow *guarantee* that no
kernel thread is active? Doesn't look like it; however we can
get close by decreasing a ref count just before returning
from the module. (There may still be return instructions etc.
that will get run). This may not be an issue with the timer
based scanning we are using currently.
* Find out why we get hangs with rawhide kernels. This only happens with the
'trace "current"' code. See this mail: