All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Hellstrom <thomas@shipmail.org>
To: "Marek Olšák" <maraeo@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write
Date: Mon, 24 Oct 2011 18:47:12 +0200	[thread overview]
Message-ID: <4EA59690.2020601@shipmail.org> (raw)
In-Reply-To: <CAAxE2A6c5KoHDrpJcMPbZvvMSbFA9tkQ4yCHfbsoo8NntoOgPQ@mail.gmail.com>

On 10/24/2011 06:42 PM, Marek Olšák wrote:
> On Sat, Oct 8, 2011 at 1:32 PM, Thomas Hellstrom<thomas@shipmail.org>  wrote:
>    
>> On 10/08/2011 01:27 PM, Ville Syrjälä wrote:
>>      
>>> On Sat, Oct 08, 2011 at 01:10:13PM +0200, Thomas Hellstrom wrote:
>>>
>>>        
>>>> On 10/08/2011 12:26 PM, Ville Syrjälä wrote:
>>>>
>>>>          
>>>>> On Fri, Oct 07, 2011 at 10:58:13AM +0200, Thomas Hellstrom wrote:
>>>>>
>>>>>
>>>>>            
>>>>>> Oh, and one more style comment below:
>>>>>>
>>>>>> On 08/07/2011 10:39 PM, Marek Olšák wrote:
>>>>>>
>>>>>>
>>>>>>              
>>>>>>> +enum ttm_buffer_usage {
>>>>>>> +    TTM_USAGE_READ = 1,
>>>>>>> +    TTM_USAGE_WRITE = 2,
>>>>>>> +    TTM_USAGE_READWRITE = TTM_USAGE_READ | TTM_USAGE_WRITE
>>>>>>> +};
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>> Please don't use enums for bit operations.
>>>>>>
>>>>>>
>>>>>>              
>>>>> Now I'm curious. Why not?
>>>>>
>>>>>
>>>>>
>>>>>            
>>>> Because it's inconsistent with how flags are defined in the rest of the
>>>> TTM module.
>>>>
>>>>          
>>> Ah OK. I was wondering if there's some subtle technical issue involved.
>>> I've recently gotten to the habit of using enums for pretty much all
>>> constants. Just easier on the eye IMHO, and avoids cpp output from
>>> looking like number soup.
>>>
>>>
>>>        
>> Yes, there are a number of advantages, including symbolic debugger output.
>> If we had flag enums that enumerated 1, 2, 4, 8 etc. I'd feel motivated to
>> move
>> all TTM definitions over.
>>      
> I don't think that how it is enumerated matters in any way. What I
> like about enums, besides what has already been mentioned, is that it
> adds a self-documentation in the code. Compare:
>
> void ttm_set_bo_flags(unsigned flags);
>
> And:
>
> void ttm_set_bo_flags(enum ttm_bo_flags flags);
>
> The latter is way easier to understand for somebody who doesn't know
> the code and wants to implement his first patch. With the latter, it's
> clear at first glance what are the valid values for "flags", because
> you can just search for "enum ttm_bo_flags".
>
> I will change the enum to defines for the sake of following your code
> style convention, but it's an unreasonable convention to say the
> least.
>
> Marek
>    

I'm not going to argue against this, because you're probably right.

The important thing is that we get the fix in with or without enums.

Thanks,
Thomas



_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

      reply	other threads:[~2011-10-24 16:49 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-07 20:39 [PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write Marek Olšák
2011-08-07 20:39 ` [PATCH 2/2] drm/radeon/kms: add a new gem_wait ioctl with read/write flags Marek Olšák
2011-08-12 17:22   ` Jerome Glisse
2011-08-12 17:21 ` [PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write Jerome Glisse
2011-08-13 20:32   ` Marek Olšák
2011-10-04 11:48 ` Thomas Hellstrom
2011-10-05  2:08   ` Marek Olšák
2011-10-05  5:54     ` Thomas Hellstrom
2011-10-06 22:42       ` Marek Olšák
2011-10-07  8:00         ` Thomas Hellstrom
2011-10-07 13:24           ` Alex Deucher
2011-10-07 14:05             ` Thomas Hellstrom
2011-10-07 14:14               ` Alex Deucher
2011-10-07 13:38           ` Jerome Glisse
2011-10-07 13:42             ` Jerome Glisse
2011-10-07 21:07               ` Marek Olšák
2011-10-07 14:09             ` Thomas Hellstrom
2011-10-07 21:30             ` Marek Olšák
2011-10-08  8:14               ` Thomas Hellstrom
2011-10-07 22:03           ` Marek Olšák
2011-10-24 14:48             ` Thomas Hellstrom
2011-10-24 17:10               ` Marek Olšák
2011-10-24 17:28                 ` Thomas Hellstrom
2011-10-24 17:39                   ` Marek Olšák
2011-10-07  8:58 ` Thomas Hellstrom
2011-10-08 10:26   ` Ville Syrjälä
2011-10-08 11:10     ` Thomas Hellstrom
2011-10-08 11:27       ` Ville Syrjälä
2011-10-08 11:32         ` Thomas Hellstrom
2011-10-24 16:42           ` Marek Olšák
2011-10-24 16:47             ` Thomas Hellstrom [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EA59690.2020601@shipmail.org \
    --to=thomas@shipmail.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=maraeo@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.