From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756268AbbFCRMD (ORCPT ); Wed, 3 Jun 2015 13:12:03 -0400 Received: from arcturus.aphlor.org ([188.246.204.175]:41463 "EHLO arcturus.aphlor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753839AbbFCRLy (ORCPT ); Wed, 3 Jun 2015 13:11:54 -0400 Date: Wed, 3 Jun 2015 13:11:34 -0400 From: Dave Jones To: Ingo Molnar Cc: Peter Zijlstra , Thomas Gleixner , "H. Peter Anvin" , linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH] x86: Cleanup Kconfig Message-ID: <20150603171134.GA5243@codemonkey.org.uk> Mail-Followup-To: Dave Jones , Ingo Molnar , Peter Zijlstra , Thomas Gleixner , "H. Peter Anvin" , linux-kernel@vger.kernel.org References: <20150602091455.GW19282@twins.programming.kicks-ass.net> <20150602113542.GA3443@gmail.com> <20150602153027.GU3644@twins.programming.kicks-ass.net> <20150603072621.GA27705@gmail.com> <20150603074132.GA1092@gmail.com> <20150603135915.GA4446@codemonkey.org.uk> <20150603161922.GA12297@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150603161922.GA12297@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Report: Spam report generated by SpamAssassin on "arcturus.aphlor.org" Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Authenticated-User: davej@codemonkey.org.uk Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 03, 2015 at 06:19:22PM +0200, Ingo Molnar wrote: > > On Wed, Jun 03, 2015 at 09:41:32AM +0200, Ingo Molnar wrote: > > > > > > > select GENERIC_CLOCKEVENTS_BROADCAST if X86_64 || (X86_32 && X86_LOCAL_APIC) > > > > > > Btw., could we (in a separate patch) turn this into: > > > > > > > select GENERIC_CLOCKEVENTS_BROADCAST > > > > > > x86 systems without an APIC are rare and rarely tested, we are better off > > > simplifying our clockevents layout. > > > > There's a ton of code in arch/x86 for cpus that don't have apic. Anything Cyrix > > pre-VIA buy out, Anything AMD pre Athlon, did Intel have apic on 486 ? > > Transmeta ? > > > > I'm all for abandoning support for 2 decade old junk, but given how long it took > > to drop 386, I wouldn't be surprised if there are still a lot of 586 era people > > still out there playing doom and wearing clothes that are about to come back > > into fashion. > > We are not desupporting them in any way - we just simplify a generic clockevents > bit by always enabling it. For some reason I thought the generic events code implied the need for an apic. Probably the misleading dependancy. Dave