Messages in this thread | | | From | Rusty Russell <> | Subject | Re: kprobes: get rid of distinct type warning | Date | Tue, 5 Jan 2010 09:15:41 +1030 |
| |
On Tue, 5 Jan 2010 02:27:02 am Heiko Carstens wrote: > On Wed, Dec 30, 2009 at 01:29:45PM -0800, Andrew Morton wrote: > > On Mon, 21 Dec 2009 13:02:24 +0100 > > Heiko Carstens <heiko.carstens@de.ibm.com> wrote: > > > > > Of course the patch wouldn't help for CONFIG_PREEMPT and !CONFIG_SMP since > > > we would have a comparison of a signed and and unsigned value again *sigh*. > > > > We should fix that, shouldn't we? Rather than working around it at one > > caller site. > > > > : #if NR_CPUS > 1 > > : #define num_online_cpus() cpumask_weight(cpu_online_mask) > > : #define num_possible_cpus() cpumask_weight(cpu_possible_mask) > > : #define num_present_cpus() cpumask_weight(cpu_present_mask) > > : #define num_active_cpus() cpumask_weight(cpu_active_mask) > > : #define cpu_online(cpu) cpumask_test_cpu((cpu), cpu_online_mask) > > : #define cpu_possible(cpu) cpumask_test_cpu((cpu), cpu_possible_mask) > > : #define cpu_present(cpu) cpumask_test_cpu((cpu), cpu_present_mask) > > : #define cpu_active(cpu) cpumask_test_cpu((cpu), cpu_active_mask) > > : #else > > : #define num_online_cpus() 1 > > : #define num_possible_cpus() 1 > > : #define num_present_cpus() 1 > > : #define num_active_cpus() 1 > > : #define cpu_online(cpu) ((cpu) == 0) > > : #define cpu_possible(cpu) ((cpu) == 0) > > : #define cpu_present(cpu) ((cpu) == 0) > > : #define cpu_active(cpu) ((cpu) == 0) > > : #endif > > > > The num_*() "functions" return unsigned on SMP and int on UP. This is > > wrong. > > > > The cpu_*() "functions" got lucky and return int in both cases. > > > > Personally I think it's neatest if a quantity which can never be > > negative is held in an unsigned type. Than includes anything starting > > with "num". But for expediency's sake we could live with making these > > things consistently return "int". > > > > Alas, changing those four num_*() "functions" to return int on SMP is a > > pretty wide-reaching change and will probably expose warts. > > Looks like there are quite a lot of num_* function usages in the kernel. > Some seem to assume they return an int some assume an unsigned int. > Don't know if it's worth changing anything here. > Maybe Rusty has an opinion.
If we have to go one way or the other, go with unsigned.
What does such a patch look like?
Thanks, Rusty.
| |