mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Dave Hansen <haveblue@us.ibm.com>
Cc: linux-kernel@vger.kernel.org, serue@us.ibm.com,
	frankeh@watson.ibm.com, clg@fr.ibm.com,
	Herbert Poetzl <herbert@13thfloor.at>,
	Sam Vilain <sam@vilain.net>
Subject: Re: [RFC][PATCH 1/6] prepare sysctls for containers
Date: Sun, 19 Mar 2006 08:29:24 -0700	[thread overview]
Message-ID: <m1veuawizv.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20060306235249.880CB28A@localhost.localdomain> (Dave Hansen's message of "Mon, 06 Mar 2006 15:52:49 -0800")

Dave Hansen <haveblue@us.ibm.com> writes:

> Right now, sysctls can only deal with global variables.  This
> patch makes them a _little_ more flexible by allowing there to
> be an accessor function to get at the variable being changed,
> instead of it being global.
>
> This allows the sysctls to be backed by variables that are,
> for instance, dynamically allocated and not available at
> compile-time.
>
> This also provides a very simple mechanism to take things that
> are currently global and containerize them.

Sorry for taking so long to look at this I just spotted this
series of patches.

The parameters that describe the variable are:
data, maxlen, extra1, and extra2.

I am concerned that this does not provide a capability for
anything except data to vary at runtime.

Also so that we can do a good job and report process local resources
in /proc this data_access should take a task_struct parameter.

data_access should also be passed the the ctl_table in case
we can make an generic data accessor.

That would allow us to put offsetof is data and then
simply add currrent->ipc_context to get the address of
the variable.  Which should keep the number of accessor functions
down.

Which give a signature something like:

struct ctl_data_info {
       void *data;
       int maxlen;
       void *extra1;
       void *extra2;
};

void ctl_data_access(struct ctl_table *tbl, sruct task_struct *task, 
			struct ctl_data_info *info);


> Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
> ---
>
>  work-dave/include/linux/sysctl.h |    8 ++++
>  work-dave/kernel/sysctl.c | 65 ++++++++++++++++++++++++++-------------
>  2 files changed, 52 insertions(+), 21 deletions(-)
>
> diff -puN include/linux/sysctl.h~sysctls-for-containers include/linux/sysctl.h
> --- work/include/linux/sysctl.h~sysctls-for-containers 2006-03-06
> 15:41:55.000000000 -0800
> +++ work-dave/include/linux/sysctl.h	2006-03-06 15:41:55.000000000 -0800
> @@ -872,6 +872,7 @@ extern void sysctl_init(void);
>  
>  typedef struct ctl_table ctl_table;
>  
> +typedef void *ctl_data_access (void);
>  typedef int ctl_handler (ctl_table *table, int __user *name, int nlen,
>  			 void __user *oldval, size_t __user *oldlenp,
>  			 void __user *newval, size_t newlen, 
> @@ -957,6 +958,13 @@ struct ctl_table 
>  	int ctl_name;			/* Binary ID */
>  	const char *procname;		/* Text ID for /proc/sys, or zero */
>  	void *data;
> +	ctl_data_access *data_access;	/* set this to a function if you
> +					 * don't have a static place to point
> +					 * ->data at compile-time.  This
> + * function will be called to dynamically
> +					 * figure out a ->data pointer.  Do not
> +					 * set this and ->data at once.
> +					 */
>  	int maxlen;
>  	mode_t mode;
>  	ctl_table *child;
> diff -puN kernel/sysctl.c~sysctls-for-containers kernel/sysctl.c
> --- work/kernel/sysctl.c~sysctls-for-containers 2006-03-06 15:41:55.000000000
> -0800
> +++ work-dave/kernel/sysctl.c	2006-03-06 15:41:55.000000000 -0800
> @@ -1197,6 +1197,24 @@ repeat:
>  	return -ENOTDIR;
>  }
>  
> +void *sysctl_table_data(ctl_table *table)
> +{
> +	void *data;
> +
> +	if (table->data && table->data_access) {
> +		printk(KERN_WARNING
> +			"sysctl: data and accessor function set for: '%s'\n",
> +			table->procname);
> +		table->data = NULL;
> +	}
> +
> +	data = table->data;
> +	if (!data && table->data_access)
> +		data = table->data_access();
> +
> +	return data;
> +}

I think we should always call data_access if it is populated.

For the rest it looks like it is getting there.

Eric

  parent reply	other threads:[~2006-03-19 15:30 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-06 23:52 [RFC][PATCH 0/6] support separate namespaces for sysv Dave Hansen
2006-03-06 23:52 ` [RFC][PATCH 1/6] prepare sysctls for containers Dave Hansen
2006-03-07  0:50   ` Herbert Poetzl
2006-03-07  2:00     ` Dave Hansen
2006-03-07  2:45       ` Herbert Poetzl
2006-03-19 15:54         ` Eric W. Biederman
2006-03-07  1:01   ` Chris Wright
2006-03-07  2:04     ` Dave Hansen
2006-03-07  2:18       ` Chris Wright
2006-03-07  3:02       ` Sam Vilain
2006-03-07  1:24   ` Al Viro
2006-03-07  1:55     ` Dave Hansen
2006-03-07  1:57       ` Al Viro
2006-03-19 14:50         ` Eric W. Biederman
2006-03-19 15:29   ` Eric W. Biederman [this message]
2006-03-06 23:52 ` [RFC][PATCH 3/6] sysvmsg: containerize sysctls Dave Hansen
2006-03-06 23:52 ` [RFC][PATCH 2/6] sysvmsg: containerize Dave Hansen
2006-03-07  1:57   ` Chris Wright
2006-03-07  2:08     ` Dave Hansen
2006-03-07  2:34       ` Chris Wright
2006-03-19 15:36         ` Eric W. Biederman
2006-03-20 19:34           ` Chris Wright
2006-03-20 21:29             ` Eric W. Biederman
2006-03-20 21:50               ` Chris Wright
2006-03-06 23:52 ` [RFC][PATCH 4/6] sysvsem: containerize Dave Hansen
2006-03-07  2:44   ` Chris Wright
2006-03-07  5:08     ` Dave Hansen
2006-03-06 23:52 ` [RFC][PATCH 5/6] sysvshm: containerize Dave Hansen
2006-03-06 23:52 ` [RFC][PATCH 6/6] sysvshm: containerize sysctls Dave Hansen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1veuawizv.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=clg@fr.ibm.com \
    --cc=frankeh@watson.ibm.com \
    --cc=haveblue@us.ibm.com \
    --cc=herbert@13thfloor.at \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@vilain.net \
    --cc=serue@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®