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