Re: [patch 1/2] fork_connector: add a fork connector

[Jay Lan <jlan@engr.sgi.com>]

Ram wrote:
> On Tue, 2005-03-22 at 11:22, Evgeniy Polyakov wrote:
> 
>>On Tue, 22 Mar 2005 10:26:19 -0800
>>Ram <linuxram@us.ibm.com> wrote:
>>
>>
>>>On Mon, 2005-03-21 at 23:07, Guillaume Thouvenin wrote:
>>>
>>>>On Mon, 2005-03-21 at 12:52 -0800, Ram wrote:
>>>>
>>>>>     If a bunch of applications are listening for fork events, 
>>>>>     your patch allows any application to turn off the 
>>>>>     fork event notification?  Is this the right behavior?
>>>>
>>>>Yes it is. The main management is done by application so, if several
>>>>applications are listening for fork events you need to choose which one
>>>>will turn off the fork connector. 
>>>>
>>>>I want to keep this turn on/off mechanism simple but if it's needed I
>>>>can manage the variable "cn_fork_enable" as a counter. Thus the callback
>>>>could be something like:
>>>>
>>>>static void cn_fork_callback(void *data)
>>>>{
>>>>  int start; 
>>>>  struct cn_msg *msg = (struct cn_msg *)data;
>>>>
>>>>  if (cn_already_initialized && (msg->len == sizeof(cn_fork_enable))) {
>>>>    memcpy(&start, msg->data, sizeof(cn_fork_enable));
>>>>    if (start)
>>>>      cn_fork_enable++;
>>>>    else
>>>>      cn_fork_enable > 0 ? cn_fork_enable-- : 0;
>>>>  }
>>>>}
>>>
>>>I think a better way is:
>>>
>>>   Providing a different connector channel called the administrator 
>>>   channel which can be used only by a super-user, and gives you
>>>   the ability to switch on or off any connector channel including the
>>>   fork-connector channel.
>>
>>Only super-user can bind netlink socket to multicast group.
> 
> 
> ok. I did not realize that.
> 
> 
>>>   For lack of better term I am using the word 'channel' to mean
>>>   something that carries events of particular type through the
>>>   connector-infrastructure.
>>
>>I still do not see why it is needed.
>>Super-user can run ip command and turn network interface off
>>not waiting while apache or named exits or unbind.
>>
>>In theory I can create some kind of userspace registration mechanism,
>>when userspace application reports it's pid to the connector, 
>>and then it sends data to the specified pids, but does not 
>>allow controlling from userspace.
>>But I really do not think it is a good idea to permit
>>non-priviledged userspace processes to know about deep
>>kernel internals through connector's messages.
> 
> 
> Yes. non-priviledged userspace processes should not know
> any deep kernel internals through connector events.
> 
> I think what I am driving at is, an application that is critically
> dependent on the fork-notification, suddenly stops receiving such
> notification because some other application has switched off the 
> service without its notice. 
> 
> the reason I am concerned is I am planning to feed this fork-events
> to my in-kernel module. Side note: I would really like support for
> in-kernel listners through connector infrastructure.

Listners in the kernel? Sound like a PAGG thing again!

Guillaume's stuff was originally an in-kernel module. CSA/Job
are kernel modules also. We all use hook management feature of PAGG,
which offer event notification to other kernel components.

Guillaume moved to connector approach and i am moving to that
direction too because Andrew likes to see in-kernel modules moved
to user space.

It is kind of funny to see someone trying to get a notification
through a connector and then feed it back to the kernel! This
does not sound right to me!

- jay

> 
> RP
> 
> 
>>>RP
>>>
>>>
>>>
>>>>
>>>>What do you think about this implementation? 
>>>>
>>>>Guillaume
>>>>
>>
>>
>>	Evgeniy Polyakov
>>
>>Only failure makes us experts. -- Theo de Raadt