lkml.org 
[lkml]   [2006]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    SubjectRe: [RFC][PATCH 1/6] prepare sysctls for containers
    From
    Date
    On Tue, 2006-03-07 at 01:50 +0100, Herbert Poetzl wrote:
    > On Mon, Mar 06, 2006 at 03:52:49PM -0800, Dave Hansen wrote:
    > >
    > > 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.
    >
    > hmm, why do you call the sysctl_table_data() over and
    > over again? what's the purpose?

    Letting me be lazy and code with s/// :)

    For the current application, it doesn't really matter. But, I can
    imagine that other users could be a bit more costly.

    > what about sideeffects?

    Require that there aren't any. ;)

    It might be necessary to have something effectively implementing put and
    get, but this certainly doesn't need it yet.

    > > 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;
    > > }
    > >
    >
    > I'd expect that to be inline, and to vanish when
    > containers are disabled ...

    Unless we want non-container code to be able to use it. I guess we
    could restrict it to containers only, though.

    > > +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;
    >
    > why is ->data and ->data_access evil?

    As it stands, which one do you use? What if they aren't consistent? Do
    you use both? Just one? Which first? Easiest to just say that it
    isn't allowed.

    > wouldn't some get/set helper make more sense?
    > i.e. some virtualizer and devirtualizer functions?

    I'm not quite sure I know what you mean. Can you elaborate some more?

    -- Dave
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-03-07 03:03    [W:5.316 / U:0.112 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site