Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757528AbYCMWmQ (ORCPT ); Thu, 13 Mar 2008 18:42:16 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753020AbYCMWmA (ORCPT ); Thu, 13 Mar 2008 18:42:00 -0400 Received: from mtagate5.uk.ibm.com ([195.212.29.138]:64707 "EHLO mtagate5.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752514AbYCMWmA (ORCPT ); Thu, 13 Mar 2008 18:42:00 -0400 Date: Thu, 13 Mar 2008 23:40:53 +0100 From: Heiko Carstens To: Martin Schwidefsky Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org Subject: Re: [patch 06/10] cpu topology support for s390. Message-ID: <20080313224053.GA5836@osiris.boeblingen.de.ibm.com> References: <20080312173155.703966894@de.ibm.com> <20080312173217.505558934@de.ibm.com> <20080312161137.63bdfa67.akpm@linux-foundation.org> <1205411307.26537.64.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1205411307.26537.64.camel@localhost> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1806 Lines: 40 On Thu, Mar 13, 2008 at 01:28:27PM +0100, Martin Schwidefsky wrote: > On Wed, 2008-03-12 at 16:11 -0700, Andrew Morton wrote: > > > +#define CPU_BITS 64 > > > + > > > +struct tl_cpu { > > > + unsigned char reserved[6]; > > > + unsigned short origin; > > > + unsigned long mask[CPU_BITS / BITS_PER_LONG]; > > > +}; > > > > mask[] will be too small for CPU_BITS=65 ;) > > We could add the +(BITS_PER_LONG - 1) logic but what for? The CPU_BITS > is defined right above and it will be increased in steps of 64. It will always be 64 and won't be increased. For more than 64 cpus "origin" in the hardware structure above will be > 0 and each bit in the mask would represent cpu "origin + bit number". > > > + end = (union tl_entry *)((unsigned long)info + info->length); > > > > I'd suggest that you take a look at all the pointer arith games which are > > being played in this code and see if it can be done better with a more > > appropriate use of the C type system. Before someone dies. > > The only thing that I can see that we could do is to get rid of the > unions and do the pointer arithmetic with the tl_cpu / tl_container > structs by hand. The data stored by ptf is structured in a way that > makes it rather hard to write decent C code. Please leave as is. I did have a few different implementations but they all looked even worse than this one. If you read the hardware specs then the current code should be rather easily understandable. And since the whole documentation is publically availabe in the meantime I could even add some comments ;) -- 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/