linux-kernel - Re: Voyager phys_cpu_present

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 21 Apr 2008 16:57:11 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Adrian Bunk <bunk@...nel.org>,
	Alexey Starikovskiy <astarikovskiy@...e.de>,
	tglx@...utronix.de, hpa@...or.com, linux-kernel@...r.kernel.org
Subject: Re: Voyager phys_cpu_present_map compile error

On Mon, 2008-04-21 at 22:14 +0200, Ingo Molnar wrote:
> * Adrian Bunk <bunk@...nel.org> wrote:
> 
> > > +#ifndef CONFIG_X86_VOYAGER
> > >  /* Bitmask of physically existing CPUs */
> > >  physid_mask_t phys_cpu_present_map;
> > > +#endif
> > >...
> > 
> > Alexey noted that phys_cpu_present_map for Voyager and !Voyager also 
> > have different types and suggested to make the Voyager one static 
> > instead (additional renaming of the Voyager one also makes sense).
> 
> yep, done by the patch below.

Hang on; this doesn't looks like such a good idea.  Why don't the
definitions match?  CPU type maps are supposed to be of type cpumask_t,
so why bother reinventing a physid_mask_t which is essentially a cut and
paste cpumask_t but on MAX_APICS instead of NR_CPUS ... surely we don't
have to have that duplication ... particularly as m32r has gone and
copied your definitions.

I'm guessing you want large sparse phys maps and smaller logical cpumaps
(although I'm not clear which archs can have a greater physical id than
they support as cpus)?  In which case, it still makes sense for this to
be generic, using similar code in  linux/cpumask.h to avoid further
duplication?

James

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/