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
14 matches
Mail list logo
