Date: Fri, 17 Nov 2006 09:06:12 +0200
From: Muli Ben-Yehuda <muli@il.ibm.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Yitzchak Eidus <ieidus@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: changing internal kernel system mechanism in runtime by a module patch
Message-ID: <20061117070612.GE3735@rhun.zurich.ibm.com>
References: <e7aeb7c60611161119h3e198e96va07d36d5b2dd6390@mail.gmail.com> <20061117064732.GC3735@rhun.zurich.ibm.com> <20061117065828.GA25155@infradead.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20061117065828.GA25155@infradead.org>
User-Agent: Mutt/1.5.11
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1130
Lines: 29

On Fri, Nov 17, 2006 at 06:58:29AM +0000, Christoph Hellwig wrote:

> This kind of stuff is just sick.  Better let them play with their research
> OS for this kind of thing :)

sick, research, what's the difference? :-)

> In practice any non-trivial bug fix requires
> changes to global data structures so reloading a module doesn't make
> sense.

... unless you have a mechanism (which k42 does) to interpose between
data structures and the users of said structures, which you can use to
decide when to repace them.

> And for module-specific problems you should be able to hack around using
> kprobes if you really need (but then again for a mission critical system
> you should have proper active-active failover clustering anyway)

I'm not advocating we merge this - nor have I seen the implementation
for Linux yet - no need to preemptively scorch it from orbit :-)

Cheers,
Muli
-
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/