From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH 1/1] x86: fix text_poke Date: Fri, 25 Apr 2008 14:02:07 -0700 (PDT) Message-ID: <20080425.140207.55069805.davem@davemloft.net> References: <48123C9B.9020306@zytor.com> <20080425203717.GB25950@Krystal> <481241DC.3070601@zytor.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mathieu.desnoyers@polymtl.ca, andi@firstfloor.org, torvalds@linux-foundation.org, mingo@elte.hu, jirislaby@gmail.com, zdenek.kabelac@gmail.com, rjw@sisk.pl, paulmck@linux.vnet.ibm.com, akpm@linux-foundation.org, linux-ext4@vger.kernel.org, herbert@gondor.apana.org.au, penberg@cs.helsinki.fi, clameter@sgi.com, linux-kernel@vger.kernel.org, pageexec@freemail.hu, jeremy@goop.org To: hpa@zytor.com Return-path: Received: from 74-93-104-97-Washington.hfc.comcastbusiness.net ([74.93.104.97]:44764 "EHLO sunset.davemloft.net" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1757646AbYDYVCH (ORCPT ); Fri, 25 Apr 2008 17:02:07 -0400 In-Reply-To: <481241DC.3070601@zytor.com> Sender: linux-ext4-owner@vger.kernel.org List-ID: From: "H. Peter Anvin" Date: Fri, 25 Apr 2008 13:41:00 -0700 > Yes, that should work. It's still ugly, and I have to say I find the > complexity rather distasteful. I am willing to be convinced it's worth > it, but I would really like to see hard numbers. This stuff would have been a lot easier if it just worked with normal relocations generated by the assembler, and that would work in such a straightforward way on EVERY architecture. The immediate instance generators could just use macros that architectures define, which are given a range of legal values for the immediate, and the macro emits the inline asm sequence that can support an immediate value of that range. Then we do a half-link of the kernel, collect the unresolved relocations from generated by the immediate macros into a table which gets linked into the kernel, then resolve them in the final link all to zero or some defined initial value. Then it's just a matter of running through the relocation handling we already have for module loading when changing an immediate value. None of this crazy instruction parsing and branch following crap. I can't believe we're seriously considering this crud. :-/