Re: [PATCH RFC 092/111] staging: etnaviv: convert to_etnaviv_bo() to real function

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

 



2015-04-02 18:29 GMT+02:00 Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>:
> On Thu, Apr 02, 2015 at 05:30:34PM +0200, Lucas Stach wrote:
>> This provides a bit more type safety.
>>
>> Signed-off-by: Lucas Stach <l.stach@xxxxxxxxxxxxxx>
>> ---
>>  drivers/staging/etnaviv/etnaviv_gem.h | 7 ++++++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/etnaviv/etnaviv_gem.h b/drivers/staging/etnaviv/etnaviv_gem.h
>> index cfade337d4db..fadd5198b3e8 100644
>> --- a/drivers/staging/etnaviv/etnaviv_gem.h
>> +++ b/drivers/staging/etnaviv/etnaviv_gem.h
>> @@ -75,7 +75,12 @@ struct etnaviv_gem_object {
>>
>>       struct etnaviv_gem_userptr userptr;
>>  };
>> -#define to_etnaviv_bo(x) container_of(x, struct etnaviv_gem_object, base)
>> +
>> +static inline
>> +struct etnaviv_gem_object *to_etnaviv_bo(struct drm_gem_object *obj)
>> +{
>> +     return container_of(obj, struct etnaviv_gem_object, base);
>> +}
>
> I've always wondered about patches like this, and wondered how they're
> supposed to be more type safe.
>
> The only thing which I can see is that the inline function will warn if
> you pass it a const or volatile pointer, whereas container_of() will
> only warn if it's passed a volatile pointer.  Apart from that, I don't
> see any difference between the two.

Eclipse CDT is happier with functions then macros in some case. I have
no opinion
about this patch.

--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel





[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux