[PATCH] cpuset export symbols gpl

[PATCH] cpuset export symbols gpl

[Paul Jackson]

Export the more useful cpuset routines for use by gpl modules.

Signed-off-by: Paul Jackson <pj@sgi.com>

---

 kernel/cpuset.c |    5 +++++
 1 files changed, 5 insertions(+)

--- 2.6.14-mm2.orig/kernel/cpuset.c	2005-11-15 16:05:12.717155260 -0800
+++ 2.6.14-mm2/kernel/cpuset.c	2005-11-15 16:14:25.425450732 -0800
@@ -1945,6 +1945,7 @@ cpumask_t cpuset_cpus_allowed(const stru
 
 	return mask;
 }
+EXPORT_SYMBOL_GPL(cpuset_cpus_allowed);
 
 void cpuset_init_current_mems_allowed(void)
 {
@@ -1980,6 +1981,7 @@ done:
 	if (need_to_refresh)
 		refresh_mems();
 }
+EXPORT_SYMBOL_GPL(cpuset_update_current_mems_allowed);
 
 /**
  * cpuset_zonelist_valid_mems_allowed - check zonelist vs. curremt mems_allowed
@@ -1999,6 +2001,7 @@ int cpuset_zonelist_valid_mems_allowed(s
 	}
 	return 0;
 }
+EXPORT_SYMBOL_GPL(cpuset_zonelist_valid_mems_allowed);
 
 /*
  * nearest_exclusive_ancestor() - Returns the nearest mem_exclusive
@@ -2079,6 +2082,7 @@ int cpuset_zone_allowed(struct zone *z, 
 	up(&callback_sem);
 	return allowed;
 }
+EXPORT_SYMBOL_GPL(cpuset_zone_allowed);
 
 /**
  * cpuset_excl_nodes_overlap - Do we overlap @p's mem_exclusive ancestors?
@@ -2121,6 +2125,7 @@ done:
 
 	return overlap;
 }
+EXPORT_SYMBOL_GPL(cpuset_excl_nodes_overlap);
 
 /*
  * Collection of memory_pressure is suppressed unless

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

Re: [PATCH] cpuset export symbols gpl

[Andrew Morton]

Paul Jackson <pj@sgi.com> wrote:
>
> Export the more useful cpuset routines for use by gpl modules.
>

We normally would do this when such modules are merged.  Do tell us more..

Re: [PATCH] cpuset export symbols gpl

[Paul Jackson]

Andrew wrote (of exporting cpuset symbols)
> We normally would do this when such modules are merged.  Do tell us more..

It was an oversight not to do this when cpusets went in last year,
but we didn't notice, as the loadable module we cared about had a
hack in place from earlier development that avoided needing this.

In cleaning this up, we realized that the module needed to access
task->cpuset->cpus_allowed, and that the correct (and safe) way to
do this, via cpuset_cpus_allowed(), was not available to the module.

The other 4 exports I added on general principles, but don't have
any pressing need for.  The one I need is cpuset_cpus_allowed().

The loadable module in question we call 'dplace', and is used to
provide fancier cpuset-relative task placement by manipulating
task->cpus_allowed at exec.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

Re: [PATCH] cpuset export symbols gpl

[Christoph Hellwig]

On Tue, Nov 15, 2005 at 06:03:36PM -0800, Paul Jackson wrote:
> Andrew wrote (of exporting cpuset symbols)
> > We normally would do this when such modules are merged.  Do tell us more..
> 
> It was an oversight not to do this when cpusets went in last year,
> but we didn't notice, as the loadable module we cared about had a
> hack in place from earlier development that avoided needing this.
> 
> In cleaning this up, we realized that the module needed to access
> task->cpuset->cpus_allowed, and that the correct (and safe) way to
> do this, via cpuset_cpus_allowed(), was not available to the module.
> 
> The other 4 exports I added on general principles, but don't have
> any pressing need for.  The one I need is cpuset_cpus_allowed().
> 
> The loadable module in question we call 'dplace', and is used to
> provide fancier cpuset-relative task placement by manipulating
> task->cpus_allowed at exec.

Again, where is the module.  Please submit the change to export the
symbols in the same patch series as that module.  And honestly I don't
think it'll survive review when it's poking that deeply into cpuset
internals, but we'll see how to do it properly once it's sent here.

Re: [PATCH] cpuset export symbols gpl

[Robin Holt]

On Wed, Nov 16, 2005 at 08:16:27AM +0000, Christoph Hellwig wrote:
> On Tue, Nov 15, 2005 at 06:03:36PM -0800, Paul Jackson wrote:
> > Andrew wrote (of exporting cpuset symbols)
> > > We normally would do this when such modules are merged.  Do tell us more..
> > 
> > It was an oversight not to do this when cpusets went in last year,
> > but we didn't notice, as the loadable module we cared about had a
> > hack in place from earlier development that avoided needing this.
> > 
> > In cleaning this up, we realized that the module needed to access
> > task->cpuset->cpus_allowed, and that the correct (and safe) way to
> > do this, via cpuset_cpus_allowed(), was not available to the module.
> > 
> > The other 4 exports I added on general principles, but don't have
> > any pressing need for.  The one I need is cpuset_cpus_allowed().
> > 
> > The loadable module in question we call 'dplace', and is used to
> > provide fancier cpuset-relative task placement by manipulating
> > task->cpus_allowed at exec.
> 
> Again, where is the module.  Please submit the change to export the
> symbols in the same patch series as that module.  And honestly I don't
> think it'll survive review when it's poking that deeply into cpuset
> internals, but we'll see how to do it properly once it's sent here.

I would argue that it does not dig deeply enough.  I think it would be
better to expand dplace to handle early-for activity.  It would be nice
to get a hook in do_fork before the call to copy_process so we can place
the child task struct on the destination instead of the source node.

That said, I could swear that dplace or something that looks a lot like
dplace was already posted on lkml, but I did not find it when I searched.
Maybe my archive is missing some stuff.

Robin

Re: [PATCH] cpuset export symbols gpl

[Paul Jackson]

Christoph wrote:
> Again, where is the module.

I will have to consult with the interested parties offline.

Nevermind this patch for now.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401