Re: [tip:core/locking] locking, x86: Slightly shorten __ticket_spin_trylock()

[Jan Beulich]

>>> Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 02.12.09 16:26 >>>
>You have zero idea what type "bool" is, do you? It can well be "int", it 
>can be "char", it can be some compiler-internal type ("_Bool"). You have 
>no idea what size it is.
>
>And maybe it _is_ just a byte. But even if it is, using 'bool' here is 
>wrong. The fact is, bool has magic semantic properties outside of sizing. 
>You can't mix it with inline asm, because you simply don't know what the 
>compiler rules for 'bool' are.
>
>For example, maybe the rules are that it's always passed as an integer, 
>and is always guaranteed to have the values 0/1. So even if 'sizeof' 
>returns 1, that doesn't actually mean that you can necessarily pass it 
>around as a char - it only means that it will take one byte in a structure 
>(except that bool arrays might be packed, I think).
>
>In other words, the semantics of 'bool' are such that you have no clue 
>what the actual ABI for 'bool' is. You cannot mix this with asm.

This just can't be the case: In order for two compilers to be
interoperable, the processor specific ABI has to define the handling of
bool, just like it has to for any other data type.

>Secondly, the notion of using a union here is just totally broken. There's 
>no point to it, and it just makes the code look horrible.

There is a point: Avoiding to have the compiler allocate yet another
register for the asm().

>So if you want to do this, then just keep 'new' as an int, and make sure 
>that the function returns a 'char'. No games with 'bool' which is badly 
>defined, no games with unions.

I considered that, but since the code means to return a boolean value,
using a char here is as bogus as (mis-)using int-s for returning boolean
values.

>And please do make sure that it actually doesn't deprove code at the 
>callers too.

Not sure what you mean here (or whether it's a typo) - neither I nor
my dictionary know the word "deprove". I assume you mean that I ought
to check that this doesn't make worse the code at the call sites, which
I did.

Jan

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