public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
	heiko.carstens@de.ibm.com
Subject: Re: [patch 06/10] cpu topology support for s390.
Date: Thu, 13 Mar 2008 13:28:27 +0100	[thread overview]
Message-ID: <1205411307.26537.64.camel@localhost> (raw)
In-Reply-To: <20080312161137.63bdfa67.akpm@linux-foundation.org>

On Wed, 2008-03-12 at 16:11 -0700, Andrew Morton wrote:
> > +#include <asm/delay.h>
> > +#include <asm/s390_ext.h>
> > +
> > +#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.

> > ...
> >
> > +static union tl_entry *next_tle(union tl_entry *tle)
> > +{
> > +	if (tle->nl)
> > +		return (union tl_entry *)((struct tl_container *)tle + 1);
> > +	else
> > +		return (union tl_entry *)((struct tl_cpu *)tle + 1);
> > +}
> 
> omg.

The length of the current tle depends on the type, the next type is
located behind the current one. Expect for the typecasting and the union
trick this is what needs to be done.

> > +static void tl_to_cores(struct tl_info *info)
> > +{
> > +	union tl_entry *tle, *end;
> > +	struct core_info *core = &core_info;
> > +
> > +	mutex_lock(&smp_cpu_state_mutex);
> > +	clear_cores();
> > +	tle = (union tl_entry *)&info->tle;
> 
> and this cast was unneeded!
> 
> > +	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.

-- 
blue skies,
  Martin.

"Reality continues to ruin my life." - Calvin.



  reply	other threads:[~2008-03-13 12:29 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-12 17:31 [patch 00/10] System z10 patches Martin Schwidefsky
2008-03-12 17:31 ` [patch 01/10] Add new fields for System z10 to /proc/sysinfo Martin Schwidefsky
2008-03-12 17:57   ` Josef 'Jeff' Sipek
2008-03-13 10:02     ` Martin Schwidefsky
2008-03-12 17:31 ` [patch 02/10] Export stfle Martin Schwidefsky
2008-03-12 17:31 ` [patch 03/10] sched: add exported arch_reinit_sched_domains() to header file Martin Schwidefsky
2008-03-12 23:03   ` Andrew Morton
2008-03-13  9:48     ` Martin Schwidefsky
2008-03-21 12:29   ` Ingo Molnar
2008-03-12 17:31 ` [patch 04/10] sched: Add arch_update_cpu_topology hook Martin Schwidefsky
2008-03-21 12:30   ` Ingo Molnar
2008-03-12 17:32 ` [patch 05/10] cpu topology: convert siblings_show macro to accept non-lvalues Martin Schwidefsky
2008-03-12 17:32 ` [patch 06/10] cpu topology support for s390 Martin Schwidefsky
2008-03-12 23:11   ` Andrew Morton
2008-03-13 12:28     ` Martin Schwidefsky [this message]
2008-03-13 22:40       ` Heiko Carstens
2008-03-12 17:32 ` [patch 07/10] Vertical cpu management Martin Schwidefsky
2008-03-12 17:32 ` [patch 08/10] Add missing TLB flush to hugetlb_cow() Martin Schwidefsky
2008-03-12 17:32 ` [patch 09/10] Hugetlb common code update for System z Martin Schwidefsky
2008-03-12 17:51   ` Dave Hansen
2008-03-12 23:18     ` Gerald Schaefer
2008-03-12 23:43       ` Andrew Morton
2008-03-13 17:49         ` Gerald Schaefer
2008-03-28 14:05         ` Gerald Schaefer
2008-03-28 14:06           ` Ingo Molnar
2008-03-28 14:33             ` Gerald Schaefer
2008-03-28 15:53             ` Martin Schwidefsky
2008-03-28 16:03               ` Ingo Molnar
2008-03-12 17:32 ` [patch 10/10] System z large page support Martin Schwidefsky
2008-03-12 17:52   ` Dave Hansen
2008-03-12 22:14     ` Gerald Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1205411307.26537.64.camel@localhost \
    --to=schwidefsky@de.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox