Re: [PATCH] Support cpu_map/cpu_mask changes in 2.6.29

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 27, 2009 at 10:27:22AM -0400, Dave Anderson wrote:
> 
> ----- "Michael Holzheu" <holzheu@xxxxxxxxxxxxxxxxxx> wrote:
> 
> > > So yes, while STRUCT_SIZE("cpumask_t") would always be appropriate for that
> > > data type, it would fail for the older kernel types which don't use it.
> > 
> > So if for older kernels it was an unsigned long, the function should
> > work:
> > 
> > +static int
> > +cpu_map_size(void)
> > +{
> > +	int len;
> > +
> > +	len = STRUCT_SIZE("cpumask_t");
> > +	if (len < 0)
> > +		return sizeof(ulong);
> > +	else
> > +		return len;
> > +}
> 
> Yeah, you're right, that will probably work.  There were definitions for
> "cpumask_t" that existed prior to the transition of cpu_online_map symbol
> from being an unsigned long to a cpumask_t.  But except for mips64 (unsupported)
> they all appear to have been unsigned longs anyway.

IIRC, cpumask_t on ia64 hasn't been an unsigned long for a very long time.
The generic_defconfig was at 512 until it recently jumped to 2048.
Only some configs limited it down to an unsigned long.  Unfortunately,
I don't have much time to test this week.  Maybe next, but a quick code
inspection should raise flags if I am remembering correctly.

Thanks,
Robin

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility

[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux