Re: [PATCH 2.6.12-rc3-mm3] connector: add a fork connector

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2005-05-09 at 15:57 +0200, Alexander Nyberg wrote:
> > +static inline void cn_fork_send_status(void)
> > +{
> > +	/* TODO: An informational line in log is maybe not enough... */
> > +	printk(KERN_INFO "cn_fork_enable == %d\n", cn_fork_enable);
> > +}
> > +
> > +/**
> > + * cn_fork_callback - enable or disable the fork connector
> > + * @data: message send by the connector 
> > + *
> > + * The callback allows to enable or disable the sending of information
> > + * about fork in the do_fork() routine. To enable the fork, the user 
> > + * space application must send the integer 1 in the data part of the 
> > + * message. To disable the fork connector, it must send the integer 0.
> > + */
> > +static void cn_fork_callback(void *data) 
> > +{
> > +	struct cn_msg *msg = data;
> > +	int action;
> > +
> > +	if (cn_already_initialized && (msg->len == sizeof(cn_fork_enable))) {
> > +		memcpy(&action, msg->data, sizeof(cn_fork_enable));
> > +		switch(action) {
> > +			case FORK_CN_START:
> > +				cn_fork_enable = 1;
> > +				break;
> > +			case FORK_CN_STOP:
> > +				cn_fork_enable = 0;
> > +				break;
> > +			case FORK_CN_STATUS:
> > +				cn_fork_send_status();
> 
> Why does this not pass down the status to the app asking about it
> instead?

I don't know exactly how to do that. A solution could be to send a
message through the connector. I think about using the following
structure:

#define FORK_CN_MSG_P   0  /* Information is about processes */
#define FORK_CN_MSG_S   1  /* Information is about status */

/*
 * The fork connector sends information to a user-space
 * application. From the user's point of view, the process
 * ID is the thread group ID and thread ID is the internal
 * kernel "pid". So, fields are assigned as follow:
 *
 *  In user space     -  In  kernel space
 *
 * parent process ID  =  parent->tgid
 * parent thread  ID  =  parent->pid
 * child  process ID  =  child->tgid
 * child  thread  ID  =  child->pid
 */
struct cn_fork_msg {
        int type;       /* 0: information about fork     
                           1: information about the status */
        int cpu;        /* ID of the cpu where the fork occured */
        union {
                struct {
                        pid_t ppid;     /* parent process ID */
                        pid_t ptid;     /* parent thread ID  */
                        pid_t cpid;     /* child process ID  */
                        pid_t ctid;     /* child thread ID   */
                };
                int status;
        };
};

And then, the cn_fork_send_status() could be coded as follow:

/**
 * cn_fork_send_status - send a message with the status
 */
static inline void cn_fork_send_status(void)
{
        struct cn_msg *msg;
        struct cn_fork_msg *forkmsg;
        __u8 buffer[CN_FORK_MSG_SIZE];

        msg = (struct cn_msg *)buffer;

        memcpy(&msg->id, &cb_fork_id, sizeof(msg->id));

        msg->ack = 0;   /* not used */
        msg->seq = 0;   /* not used */

        msg->len = CN_FORK_INFO_SIZE;
        forkmsg = (struct cn_fork_msg *)msg->data;
        forkmsg->type = FORK_CN_MSG_S;
        forkmsg->status = cn_fork_enable;

        cn_netlink_send(msg, CN_IDX_FORK, GFP_KERNEL);
}

I think this solution is good. Agree?

Best,
Guillaume.

-
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/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux