[lkml]   [2005]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Lse-tech] Re: A common layer for Accounting packages
Jay Lan <> wrote:
> Andrew Morton wrote:
> > Kaigai Kohei <> 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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:10    [W:0.091 / U:7.328 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site