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
* 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 yo
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
> > >
* 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 v
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 b
* 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?
> >
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
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
* 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_s
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? Agai
* 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 k
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 l
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 diffe
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 diffe
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 diffe
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 diffe
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 diffe
19 matches
Mail list logo
