Re: [Lse-tech] Re: A common layer for Accounting packages

[Andrew Morton <akpm@osdl.org>]

Jay Lan <jlan@sgi.com> wrote:
>
> Andrew Morton wrote:
>  > Kaigai Kohei <kaigai@ak.jp.nec.com> 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.
>  > 
>  > Question is: is this sufficient for CSA?
> 
>  Yes, fork, exec, and exit upcalls are sufficient for CSA.
> 
>  The framework i proposed earlier should satisfy your requirement a
>  and b, and provides upcalls needed by BSD, ELSA and CSA. Maybe i
>  misunderstood your concern of the 'very light weight' framework
>  i proposed besides being "overkill"?

"upcall" is poorly defined.

What I meant was that ELSA can perform its function when the kernel merely
sends asynchronous notifications of forks out to userspace via netlink.

Further, I'm wondering if CSA can perform its function with the same level
of kernel support, perhaps with the addition of netlink-based notification
of exec and exit as well.

The framework patch which you sent was designed to permit the addition of
more kernel accounting code, which is heading in the opposite direction.

In other words: given that ELSA can do its thing via existing accounting
interfaces and a fork notifier, why does CSA need to add lots more kernel
code?