From: Erik J. <er...@sg...> - 2005-09-21 22:18:40
|
> > What I propose here is Process Notification (pnotify). This is derived from > > PAGG. It's been re-worked to have some better documentation (below) and > > variable names that better reflect what is really happening. > > > Last time we discussed all this we'd pretty much worked out that all > accounting functions could be performed from userspace, as long as the > connector-based fork()/exit()/exec() notifications were in place. > > That is of course a vastly preferable approach. Do you see something which > makes it unfeasible? Unless I'm missing something (feel free to point me somewhere), my understanding was this technique is potentially lossy, right? We have customers who don't want to take even a chance that some accounting data is lost for some reason. These are the same customers who tend to use a machine to its fullest (read beat it to death :). The idea of pnotify is various kernel components can register to be notified about events in the life of any process they choose. It's somewhat similar to notifier lists, only they are per-process based and have a data pointer associated with the task. The idea here isn't to limit it just to accounting type applications. If someone has a suggestion of something in the task struct or copy_process path that could make use of this, I'd be happy to give a shot at implementing it. Perhaps something that isn't super "hot" in the task struct? If we added process notifiers for gid/uid changes, could CKRM make use of this as well (Kingsley asked me this, I said I'd look in to implementing it)? |