On Fri, 2007-09-21 at 09:37 -0400, Mathieu Desnoyers wrote:
> > Good points. Well I'd say hiding it all behind a friendly
> > "immediate_set()" interface is the best option then.
>
> Then we can't benefit of the __init section to have the code removed
> after boot. I don't see the point in doing
On Fri, 2007-09-21 at 09:37 -0400, Mathieu Desnoyers wrote:
Good points. Well I'd say hiding it all behind a friendly
immediate_set() interface is the best option then.
Then we can't benefit of the __init section to have the code removed
after boot. I don't see the point in doing so.
* Rusty Russell ([EMAIL PROTECTED]) wrote:
> On Tue, 2007-09-18 at 09:41 -0400, Mathieu Desnoyers wrote:
> > * Rusty Russell ([EMAIL PROTECTED]) wrote:
> > > On Fri, 2007-09-14 at 11:32 -0400, Mathieu Desnoyers wrote:
> > > > * Rusty Russell ([EMAIL PROTECTED]) wrote:
> > > > > Alternatively, if
* Rusty Russell ([EMAIL PROTECTED]) wrote:
On Tue, 2007-09-18 at 09:41 -0400, Mathieu Desnoyers wrote:
* Rusty Russell ([EMAIL PROTECTED]) wrote:
On Fri, 2007-09-14 at 11:32 -0400, Mathieu Desnoyers wrote:
* Rusty Russell ([EMAIL PROTECTED]) wrote:
Alternatively, if you called it
On Tue, 2007-09-18 at 09:41 -0400, Mathieu Desnoyers wrote:
> * Rusty Russell ([EMAIL PROTECTED]) wrote:
> > On Fri, 2007-09-14 at 11:32 -0400, Mathieu Desnoyers wrote:
> > > * Rusty Russell ([EMAIL PROTECTED]) wrote:
> > > > Alternatively, if you called it "immediate_init" then the semantics
> >
On Tue, 2007-09-18 at 09:41 -0400, Mathieu Desnoyers wrote:
* Rusty Russell ([EMAIL PROTECTED]) wrote:
On Fri, 2007-09-14 at 11:32 -0400, Mathieu Desnoyers wrote:
* Rusty Russell ([EMAIL PROTECTED]) wrote:
Alternatively, if you called it immediate_init then the semantics
change
* Rusty Russell ([EMAIL PROTECTED]) wrote:
> On Fri, 2007-09-14 at 11:32 -0400, Mathieu Desnoyers wrote:
> > * Rusty Russell ([EMAIL PROTECTED]) wrote:
> > > Alternatively, if you called it "immediate_init" then the semantics
> > > change slightly, but are more obvious (ie. only use this when the
* Rusty Russell ([EMAIL PROTECTED]) wrote:
On Fri, 2007-09-14 at 11:32 -0400, Mathieu Desnoyers wrote:
* Rusty Russell ([EMAIL PROTECTED]) wrote:
Alternatively, if you called it immediate_init then the semantics
change slightly, but are more obvious (ie. only use this when the value
On Fri, 2007-09-14 at 11:32 -0400, Mathieu Desnoyers wrote:
> * Rusty Russell ([EMAIL PROTECTED]) wrote:
> > Alternatively, if you called it "immediate_init" then the semantics
> > change slightly, but are more obvious (ie. only use this when the value
> > isn't being accessed yet). But it can't
On Fri, 2007-09-14 at 11:32 -0400, Mathieu Desnoyers wrote:
* Rusty Russell ([EMAIL PROTECTED]) wrote:
Alternatively, if you called it immediate_init then the semantics
change slightly, but are more obvious (ie. only use this when the value
isn't being accessed yet). But it can't be __init
* Rusty Russell ([EMAIL PROTECTED]) wrote:
> On Thu, 2007-09-13 at 17:21 -0400, Mathieu Desnoyers wrote:
> > * Rusty Russell ([EMAIL PROTECTED]) wrote:
> > > Sure, but why is that the caller's problem? immediate_set() isn't
> > > fastpath, so why not make it do an "if (early_boot)" internally?
>
* Rusty Russell ([EMAIL PROTECTED]) wrote:
On Thu, 2007-09-13 at 17:21 -0400, Mathieu Desnoyers wrote:
* Rusty Russell ([EMAIL PROTECTED]) wrote:
Sure, but why is that the caller's problem? immediate_set() isn't
fastpath, so why not make it do an if (early_boot) internally?
I see
On Thu, 2007-09-13 at 17:21 -0400, Mathieu Desnoyers wrote:
> * Rusty Russell ([EMAIL PROTECTED]) wrote:
> > Sure, but why is that the caller's problem? immediate_set() isn't
> > fastpath, so why not make it do an "if (early_boot)" internally?
>
> I see two reasons:
> 1 - early_boot, or anything
* Rusty Russell ([EMAIL PROTECTED]) wrote:
> On Tue, 2007-09-11 at 10:27 -0400, Mathieu Desnoyers wrote:
> > * Rusty Russell ([EMAIL PROTECTED]) wrote:
> > > On Mon, 2007-09-10 at 20:45 -0400, Mathieu Desnoyers wrote:
> > > > Code patching of _live_ SMP code is allowed. This is why I went through
* Rusty Russell ([EMAIL PROTECTED]) wrote:
On Tue, 2007-09-11 at 10:27 -0400, Mathieu Desnoyers wrote:
* Rusty Russell ([EMAIL PROTECTED]) wrote:
On Mon, 2007-09-10 at 20:45 -0400, Mathieu Desnoyers wrote:
Code patching of _live_ SMP code is allowed. This is why I went through
all
On Thu, 2007-09-13 at 17:21 -0400, Mathieu Desnoyers wrote:
* Rusty Russell ([EMAIL PROTECTED]) wrote:
Sure, but why is that the caller's problem? immediate_set() isn't
fastpath, so why not make it do an if (early_boot) internally?
I see two reasons:
1 - early_boot, or anything that
On Tue, 2007-09-11 at 10:27 -0400, Mathieu Desnoyers wrote:
> * Rusty Russell ([EMAIL PROTECTED]) wrote:
> > On Mon, 2007-09-10 at 20:45 -0400, Mathieu Desnoyers wrote:
> > > Code patching of _live_ SMP code is allowed. This is why I went through
> > > all this trouble on i386.
> >
> > Oh, I was
On Tue, 2007-09-11 at 10:27 -0400, Mathieu Desnoyers wrote:
* Rusty Russell ([EMAIL PROTECTED]) wrote:
On Mon, 2007-09-10 at 20:45 -0400, Mathieu Desnoyers wrote:
Code patching of _live_ SMP code is allowed. This is why I went through
all this trouble on i386.
Oh, I was pretty sure
* Rusty Russell ([EMAIL PROTECTED]) wrote:
> On Mon, 2007-09-10 at 20:45 -0400, Mathieu Desnoyers wrote:
> > Code patching of _live_ SMP code is allowed. This is why I went through
> > all this trouble on i386.
>
> Oh, I was pretty sure it wasn't. OK.
>
> So now why three versions of
* Rusty Russell ([EMAIL PROTECTED]) wrote:
On Mon, 2007-09-10 at 20:45 -0400, Mathieu Desnoyers wrote:
Code patching of _live_ SMP code is allowed. This is why I went through
all this trouble on i386.
Oh, I was pretty sure it wasn't. OK.
So now why three versions of immediate_set()?
On Mon, 2007-09-10 at 20:45 -0400, Mathieu Desnoyers wrote:
> Code patching of _live_ SMP code is allowed. This is why I went through
> all this trouble on i386.
Oh, I was pretty sure it wasn't. OK.
So now why three versions of immediate_set()? And why are you using my
lock for exclusion?
* Rusty Russell ([EMAIL PROTECTED]) wrote:
> On Sat, 2007-09-08 at 11:28 +0400, Alexey Dobriyan wrote:
> > On Thu, Sep 06, 2007 at 04:02:29PM -0400, Mathieu Desnoyers wrote:
> > > Remove "static" from module_mutex and the modules list so it can be used
> > > by
> > > other builtin objects in the
On Sat, 2007-09-08 at 11:28 +0400, Alexey Dobriyan wrote:
> On Thu, Sep 06, 2007 at 04:02:29PM -0400, Mathieu Desnoyers wrote:
> > Remove "static" from module_mutex and the modules list so it can be used by
> > other builtin objects in the kernel. Otherwise, every code depending on the
> > module
On Sat, 2007-09-08 at 11:28 +0400, Alexey Dobriyan wrote:
On Thu, Sep 06, 2007 at 04:02:29PM -0400, Mathieu Desnoyers wrote:
Remove static from module_mutex and the modules list so it can be used by
other builtin objects in the kernel. Otherwise, every code depending on the
module list
* Rusty Russell ([EMAIL PROTECTED]) wrote:
On Sat, 2007-09-08 at 11:28 +0400, Alexey Dobriyan wrote:
On Thu, Sep 06, 2007 at 04:02:29PM -0400, Mathieu Desnoyers wrote:
Remove static from module_mutex and the modules list so it can be used
by
other builtin objects in the kernel.
On Mon, 2007-09-10 at 20:45 -0400, Mathieu Desnoyers wrote:
Code patching of _live_ SMP code is allowed. This is why I went through
all this trouble on i386.
Oh, I was pretty sure it wasn't. OK.
So now why three versions of immediate_set()? And why are you using my
lock for exclusion?
On Thu, Sep 06, 2007 at 04:02:29PM -0400, Mathieu Desnoyers wrote:
> Remove "static" from module_mutex and the modules list so it can be used by
> other builtin objects in the kernel. Otherwise, every code depending on the
> module list would have to be put in kernel/module.c. Since the immediate
On Thu, Sep 06, 2007 at 04:02:29PM -0400, Mathieu Desnoyers wrote:
Remove static from module_mutex and the modules list so it can be used by
other builtin objects in the kernel. Otherwise, every code depending on the
module list would have to be put in kernel/module.c. Since the immediate
Remove "static" from module_mutex and the modules list so it can be used by
other builtin objects in the kernel. Otherwise, every code depending on the
module list would have to be put in kernel/module.c. Since the immediate values
depends on the module list but can be considered as logically
Remove static from module_mutex and the modules list so it can be used by
other builtin objects in the kernel. Otherwise, every code depending on the
module list would have to be put in kernel/module.c. Since the immediate values
depends on the module list but can be considered as logically
Remove "static" from module_mutex and the modules list so it can be used by
other builtin objects in the kernel. Otherwise, every code depending on the
module list would have to be put in kernel/module.c. Since the immediate values
depends on the module list but can be considered as logically
Remove static from module_mutex and the modules list so it can be used by
other builtin objects in the kernel. Otherwise, every code depending on the
module list would have to be put in kernel/module.c. Since the immediate values
depends on the module list but can be considered as logically
Remove "static" from module_mutex and the modules list so it can be used by
other builtin objects in the kernel. Otherwise, every code depending on the
module list would have to be put in kernel/module.c. Since the immediate values
depends on the module list but can be considered as logically
Remove static from module_mutex and the modules list so it can be used by
other builtin objects in the kernel. Otherwise, every code depending on the
module list would have to be put in kernel/module.c. Since the immediate values
depends on the module list but can be considered as logically
Remove "static" from module_mutex and the modules list so it can be used by
other builtin objects in the kernel. Otherwise, every code depending on the
module list would have to be put in kernel/module.c. Since the immediate values
depends on the module list but can be considered as logically
Remove static from module_mutex and the modules list so it can be used by
other builtin objects in the kernel. Otherwise, every code depending on the
module list would have to be put in kernel/module.c. Since the immediate values
depends on the module list but can be considered as logically
Remove "static" from module_mutex and the modules list so it can be used by
other builtin objects in the kernel. Otherwise, every code depending on the
module list would have to be put in kernel/module.c. Since the immediate values
depends on the module list but can be considered as logically
Remove static from module_mutex and the modules list so it can be used by
other builtin objects in the kernel. Otherwise, every code depending on the
module list would have to be put in kernel/module.c. Since the immediate values
depends on the module list but can be considered as logically
38 matches
Mail list logo
