Hi,

Kaigai Kohei <[EMAIL PROTECTED]> wrote:

In my understanding, what Andrew Morton said is "If target functionality can
implement in user space only, then we should not modify the kernel-tree".

fork, exec and exit upcalls sound pretty good to me. As long as

a) they use the same common machinery and

b) they are next-to-zero cost if something is listening on the netlink
  socket but no accounting daemon is running.


b) would involved being able to avoid sending netlink messages in case there are no listeners. AFAIK that isnt possible currently, netlink sends packets unconditionally.

Am I wrong?

In current implementaion, you might be right. But we should make an effort to achieve the requirement-(b) from now.

And, why can't netlink packets send always?
If there are fork/exec/exit hooks, and they call CSA or other process-grouping 
modules,
then those modules will decide whether packets for interaction with the daemon 
should be
sent or not.
In most considerable case, CSA's kernel-loadable-module using such hooks will 
not be loaded
when no accounting daemon is running. Adversely, this module must be loaded 
when accounting
daemon needs CSA's netlink packets.
Thus, it is only necessary to refer flag valiable and to execute 
conditional-jump
when no-accounting daemon is running.

In my estimation, we must pay additional cost for an increment-operation, an 
decrement-op,
an comparison-op and an conditional jump-op. It's enough lightweight, I think.

For example:
If CSA's module isn't loaded, 'privates_for_grouping' will be empty.

inline int on_fork_hook(task_struct *parent, task_struct *newtask){
  rcu_read_lock();
  if( !list_empty(&parent->privates_for_grouping) ){
    ..<Calling to any process grouping module>..;
  }
  rcu_read_unlock();
}

Thanks,
--
Linux Promotion Center, NEC
KaiGai Kohei <[EMAIL PROTECTED]>
-
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/

Reply via email to