Ingo Molnar <[EMAIL PROTECTED]> wrote: > i saw (and like) the ornaments stuff, and TUX could use it too: right now > TUX has an extra field in task_struct to do exit()-time deregistering of > processes. Linus suggested to use a more generic mechanizm. I think some > already existing things, like the SysV semaphore exit()-time cleanup > feature can be handled with the ornaments feature as well. I was thinking about this, and have come up with another possible way of using task ornaments: What if the SIGCHLD notification mechanism used it too?: (1) When a process forks a child, it would insert an ornament into that child's ornament list. This ornament would points back to itself. (2) This ornament overloads the signal and exit methods of the ornament, and would use these to obtain notification of death signals, stop signals and exits from the child (on which basis it can raise SIGCHLD in the parent process). (3) If a debugger attaches to a process, it would insert an ornament in front of the one inserted by the parent. (4) This ornament would allow the child's signals to be intercepted, and would permit the following operations to be performed: (a) raising SIGCHLD (or some other signal) in the debugger process and/or releasing of suspended wait() calls. (b) cancellation of the signal (so the child doesn't receive it), (c) prevention of propagation to ornaments further along the list. This would allow the debugger to attach _without_ reparenting the process. (5) If a debugger want's to follow-fork, then the fork notification method can be overloaded in it's ornament to stick an ornament into the forked grandchild. (6) If the process's parent dies, then (a) the process can be reparented to init, and the ornament can be simply removed. (b) the ornament can be pointed instead to another thread of the same group. If this is worthwhile doing, it may well be worth simplifying the notification iteration functions to lock the task_struct, notify all ornaments (removing those that indicate that they should be removed), drop the lock and reschedule if necessary. This means that a task ornament can't add more task ornaments to the same process, but I'm not sure this matters. It may also be worth saying that all task ornaments have to be a particular size, and using the slab memory stuff to manage them, rather than embedding them as I currently envisiage, particularly as there'd be quite a lot of them. struct task_ornament { struct task_ornament_ops *to_ops; struct list_head *to_list; void *to_private; } David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/