On Thu, 2005-02-24 at 07:41 +0100, Guillaume Thouvenin wrote:
> On Wed, 2005-02-23 at 14:41 +0300, Evgeniy Polyakov wrote:
> > > Please assume that > > originally written for> will always be listening.
> > >
> > > > > What happened to the idea of sending an on/off message down the
> > > > > netli
On Wed, 2005-02-23 at 14:41 +0300, Evgeniy Polyakov wrote:
> > Please assume that > originally written for> will always be listening.
> >
> > > > What happened to the idea of sending an on/off message down the netlink
> > > > socket?
> > ...
> > Arrange for the userspace daemon to send a message t
On Wed, 23 Feb 2005 02:58:06 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, 23 Feb 2005 01:07:47 -0800
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > > Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hello,
> > > >
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> On Wed, 23 Feb 2005 01:07:47 -0800
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
> > >
> > > Hello,
> > >
> > > This patch replaces the relay_fork module and it implements a fork
> > > connector in
On Wed, 23 Feb 2005 01:07:47 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
> >
> > Hello,
> >
> > This patch replaces the relay_fork module and it implements a fork
> > connector in the kernel/fork.c:do_fork() routine. The connector sends
> > in
Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> This patch replaces the relay_fork module and it implements a fork
> connector in the kernel/fork.c:do_fork() routine. The connector sends
> information about parent PID and child PID over a netlink interface. It
> allows to several u
Hello,
This patch replaces the relay_fork module and it implements a fork
connector in the kernel/fork.c:do_fork() routine. The connector sends
information about parent PID and child PID over a netlink interface. It
allows to several user space applications to be informed when a fork
occurs in t
Guillaume wrote:
>
> I understand your point of view but I'm using netlink interface
> because it's already in the kernel so my choice is to use something that
> is already in the kernel instead of adding dozens of new instructions
> and also to do things in user space.
All else equal, yes it is
On Monday 21 February 2005 15:43, Guillaume Thouvenin wrote:
>
> I also choose this implementation because Erich Focht wrote in the
> email http://lkml.org/lkml/2004/12/17/99 that keeps the historic about
> the creation of processes "sounds very useful for a lot of interesting
> stuff". So I tho
On Mon, 2005-02-21 at 03:58 -0800, Paul Jackson wrote:
> > It's a new patch that implements a fork connector in the
> > kernel/fork.c:do_fork() routine. The connector sends information about
> > parent PID and child PID over a netlink interface. It allows to several
> > user space applications
Thank-you for your quick answer.
Guillaume wrote:
>
> If a process belongs to several group of processes, an new integer in
> the task_struct is not enough, you need a list or something like this.
> If you're using a list you need to add function to manage this list in
> the kernel but we don't wa
On Mon, 2005-02-21 at 01:47 -0800, Paul Jackson wrote:
> Guillaume wrote:
> > The problem is the following: I have a user space daemon that manages
> > group of processes. The main idea is, if a parent belongs to a group
> > then its child belongs to the same group. To achieve this I need to know
Guillaume wrote:
> The problem is the following: I have a user space daemon that manages
> group of processes. The main idea is, if a parent belongs to a group
> then its child belongs to the same group. To achieve this I need to know
> when a fork occurs and which processes are involved. I don't
On Mon, 2005-02-21 at 09:05 +0100, Guillaume Thouvenin wrote:
> On Thu, 2005-02-17 at 18:50 +0300, Evgeniy Polyakov wrote:
> > >
> > > +#if defined(CONFIG_CONNECTOR) && defined(CONFIG_FORK_CONNECTOR)
> >
> > I suspect CONFIG_FORK_CONNECTOR is enough.
>
> The problem here is that if connector is
On Mon, 2005-02-21 at 08:07 +0100, Guillaume Thouvenin wrote:
> On Thu, 2005-02-17 at 18:50 +0300, Evgeniy Polyakov wrote:
> > On Thu, 2005-02-17 at 15:55 +0100, Guillaume Thouvenin wrote:
> > > It's a new patch that implements a fork connector in the
> > > kernel/fork.c:do_fork() routine. The
On Thu, 2005-02-17 at 18:50 +0300, Evgeniy Polyakov wrote:
> >
> > +#if defined(CONFIG_CONNECTOR) && defined(CONFIG_FORK_CONNECTOR)
>
> I suspect CONFIG_FORK_CONNECTOR is enough.
The problem here is that if connector is compiled as a module and
fork_connector as builtin there will be undefined
On Thu, 2005-02-17 at 18:50 +0300, Evgeniy Polyakov wrote:
> On Thu, 2005-02-17 at 15:55 +0100, Guillaume Thouvenin wrote:
> > It's a new patch that implements a fork connector in the
> > kernel/fork.c:do_fork() routine. The connector sends information about
> > parent PID and child PID over a
On Thu, 2005-02-17 at 15:55 +0100, Guillaume Thouvenin wrote:
> Hello,
Hello, I have small note about connector's usage in your module
in particular and others in general.
> It's a new patch that implements a fork connector in the
> kernel/fork.c:do_fork() routine. The connector sends informa
Hello,
It's a new patch that implements a fork connector in the
kernel/fork.c:do_fork() routine. The connector sends information about
parent PID and child PID over a netlink interface. It allows to several
user space applications to be alerted when a fork occurs in the kernel.
The main drawba
19 matches
Mail list logo
