On Tue, Nov 04, 2014 at 03:12:27PM -0700, Todd Previte wrote: > >Does it really need to be uint8_t? I see on patch 7 that you don't > >really write this value to a place that only accepts uint8_t-sized > >arguments, so I fear that if we get 256 NACKs or DEFERs we may end up > >doing the wrong thing. > > There are no compliance tests that are concerned with the number of native > DEFERs or NACKs received, hence why they are not addressed here. > There's no requirement for the size of this value and I selected uint8_t as > the smallest reasonable size for it. It's only used to count the number of > NACKs and DEFERs during compliance testing and it gets reset to 0 at the > beginning of the test block where it's used in a later patch. It's unlikely > that a case would occur during this compliance test where exactly 256 NACKs > or DEFERs occur, but your point is well-taken. I'll make them uint32s and be > done with it. I don't think 6 extra bytes is going to run the kernel out of > memory. :) Du to struct alignement rules a lone uint8_t will actually occupy as much as a plain unsigned. Also uint8_t in drivers has a bit the air of a carefully picked size, usually in relation to some hw limit (e.g. register size). Imo just go with unsigned, it's clearer in intent and actually doesn't use more space. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
