From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934504AbXGKWWY (ORCPT ); Wed, 11 Jul 2007 18:22:24 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1765740AbXGKWWQ (ORCPT ); Wed, 11 Jul 2007 18:22:16 -0400 Received: from smtp2.linux-foundation.org ([207.189.120.14]:59400 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1763721AbXGKWWP (ORCPT ); Wed, 11 Jul 2007 18:22:15 -0400 Date: Wed, 11 Jul 2007 15:20:31 -0700 (PDT) From: Linus Torvalds To: Thomas Gleixner cc: Ingo Molnar , Andi Kleen , Andrew Morton , linux-kernel@vger.kernel.org, Arjan van de Ven , Chris Wright Subject: Re: x86 status was Re: -mm merge plans for 2.6.23 In-Reply-To: <1184191488.12353.160.camel@chaos> Message-ID: References: <20070710013152.ef2cd200.akpm@linux-foundation.org> <20070711174252.GA16793@elte.hu> <1184191488.12353.160.camel@chaos> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 12 Jul 2007, Thomas Gleixner wrote: > > Can you please shed some light on me, how exactly you switch an > architecture gradually to clock events. For example, we can make sure that the code in question that actually touches the hardware stays exactly the same, and then just move the interfaces around - and basically guarantee that _zero_ hardware-specific issues pop up when you switch over, for example. That way there is a gradual change-over. The other approach (which would be nice _too_) is to actually try to convert one clock source at a time. Why is that not an option? Linus