change log for rtems (2011-10-07)

[Ralf Corsepius]

On 10/07/2011 05:15 PM, Peter Dufault wrote:
> (First responding to Ralf..)
>
>>>   It wasn't me who wrote the original code.
>
> I know, I did, but it was for the MPC55XX and it's being built for the MPC567X.  It's pulling in a different header file.
>
> . . .
>
>>>> so if it is compatible in any way then the reserved field of :5 needs be
>>>> cut down to :4 instead of shifting the size bit to the right.
>>> OK, if you say, so - The evilness of bitfield's sensitivity to
>>> endianness shows ;)
>
> I know what you mean,
The issue condenses down to "which bit of a bitfield is where?" when a 
bitfield is mapped onto an ordinary type or written to HW?

In general. it's compiler implementation dependent. In GCC, it's 
basically it's a matter of byte-order and of word-sizes.

> but in device-specific code you need to somehow twiddle the device's bits and I almost always follow the conventions in use.  In this case it's bitfields in register structs.
I am aware about this.

>>>
>>>
>>> Just to avoid further misunderstandings, could you send a patch for what
>>> you think is correct?
>>>
>
> We should back out your change and disable the build for anything that isn't an MPC56XX.
OK, I read this as, "this code is MPC56XX specific and must not be 
applied by the BSP which triggered the GCC warning" - right?

>  I'll try to do that Monday.
OK, I likely won't have time to investigate before, either, so I prefer 
not to touch the code and wait until then.

> On Oct 7, 2011, at 10:42 , Joel Sherrill wrote:
>
>>
>> Would issuing a compile time warning to indicate that this
>> file is not yet supported on variant X be appropriate?
>
> It did do that, though not on purpose.
Except that nobody seems to have noticed it, so far ;)

>> How would a user know this file needs attention to be useful
>> for this particular configuration?
There are too many details involved, I am not sufficiently familiar 
with, to have a clear vision on how to fix this issue (yet).

/me feels, this is a case of an "invalid generalization" of a BSP, which 
now needs to be sorted out. Of course, there is the "define" approach, 
but I am not a friend of this approach (Overly extensive use of defines 
in RTEMS is THE fundamental design flaw, RTEMS suffers from, IMO).

Ralf