litmus-rt.git - The LITMUS^RT kernel.

The LITMUS^RT kernel.

Bjoern Brandenburg

about summary refs log tree commit diff stats

diff options

author	Dave Airlie <airlied@linux.ie>	2008-08-24 03:02:26 -0400
committer	Dave Airlie <airlied@linux.ie>	2008-08-24 16:35:33 -0400
commit	3e5fc80a404a24c858468030b63555cccfb3e79c (patch)
tree	697956db50347ef93490e6220d29b11d9f7f1ee9 /fs/udf/misc.c
parent	e5b4f19417b75a2d7c1e36934f60a3e836c4337e (diff)

drm: don't set the signal blocker on the master process.

There is a problem with debugging the X server and gdb crashes in the xkb startup code. This avoids the problem by allowing the master process to get signals. It should be safe as the signal blocker is mainly so that you can Ctrl-Z a 3D application without locking up the whole box. Ctrl-Z the X server isn't something many people do. Signed-off-by: Dave Airlie <airlied@redhat.com>

Diffstat (limited to 'fs/udf/misc.c')

0 files changed, 0 insertions, 0 deletions

red using signals. The application decides which "events" it wants to be notified about. The currently defined events are: DN_ACCESS A file in the directory was accessed (read) DN_MODIFY A file in the directory was modified (write,truncate) DN_CREATE A file was created in the directory DN_DELETE A file was unlinked from directory DN_RENAME A file in the directory was renamed DN_ATTRIB A file in the directory had its attributes changed (chmod,chown) Usually, the application must reregister after each notification, but if DN_MULTISHOT is or'ed with the event mask, then the registration will remain until explicitly removed (by registering for no events). By default, SIGIO will be delivered to the process and no other useful information. However, if the F_SETSIG fcntl(2) call is used to let the kernel know which signal to deliver, a siginfo structure will be passed to the signal handler and the si_fd member of that structure will contain the file descriptor associated with the directory in which the event occurred. Preferably the application will choose one of the real time signals (SIGRTMIN + <n>) so that the notifications may be queued. This is especially important if DN_MULTISHOT is specified. Note that SIGRTMIN is often blocked, so it is better to use (at least) SIGRTMIN + 1. Implementation expectations (features and bugs :-)) --------------------------- The notification should work for any local access to files even if the actual file system is on a remote server. This implies that remote access to files served by local user mode servers should be notified. Also, remote accesses to files served by a local kernel NFS server should be notified. In order to make the impact on the file system code as small as possible, the problem of hard links to files has been ignored. So if a file (x) exists in two directories (a and b) then a change to the file using the name "a/x" should be notified to a program expecting notifications on directory "a", but will not be notified to one expecting notifications on directory "b". Also, files that are unlinked, will still cause notifications in the last directory that they were linked to. Configuration ------------- Dnotify is controlled via the CONFIG_DNOTIFY configuration option. When disabled, fcntl(fd, F_NOTIFY, ...) will return -EINVAL. Example ------- #define _GNU_SOURCE /* needed to get the defines */ #include <fcntl.h> /* in glibc 2.2 this has the needed values defined */ #include <signal.h> #include <stdio.h> #include <unistd.h> static volatile int event_fd; static void handler(int sig, siginfo_t *si, void *data) { event_fd = si->si_fd; } int main(void) { struct sigaction act; int fd; act.sa_sigaction = handler; sigemptyset(&act.sa_mask); act.sa_flags = SA_SIGINFO; sigaction(SIGRTMIN + 1, &act, NULL); fd = open(".", O_RDONLY); fcntl(fd, F_SETSIG, SIGRTMIN + 1); fcntl(fd, F_NOTIFY, DN_MODIFY|DN_CREATE|DN_MULTISHOT); /* we will now be notified if any of the files in "." is modified or new files are created */ while (1) { pause(); printf("Got event on fd=%d\n", event_fd); } }


context:
space:
mode: