Comment # 59
on bug 12687
from Michael Mann
(In reply to Oliver Hartkopp from comment #56)
> (In reply to Michael Mann from comment #54)
> > (In reply to Oliver Hartkopp from comment #53)
> > > But please make it in a way that the flags values are always(!) displayed in
> > > the same way as CAN identifier, Length, etc. Which means that there's no
> > > option to show or hide the CAN FD flags as it is presented now.
> > >
> > > A dissector for CAN FD just has do display all flags all the time.
> >
> > I'm more indifferent to this change, but I will point out that if the flags
> > are true/set, they are appended to the "FD Flags" field so you know their
> > value without expanding the tree.
>
> IMHO that doesn't fit the either use expectations nor the correct technical
> representation. We now have a separate code for CAN FD frames and display
> that protocol type 'CANFD' in the HMI accordingly.
>
> The flags that can be found in struct canfd_frame.flags are no 'CAN FD
> Flags' but are only 'flags' that describe this CAN FD frame in the same way
> the 'Extended Flag' does. I would be fine with the fact that you want to put
> the BRS and ESI flags behind the 'Frame-Length:' line to follow the
> sequential position in the PDU data.
>
> Therefore the BRS and ESI bits should be presented in the same way and
> indention as the EXT flags and without any possibility to collapse or expand
> these two bits.
I think I've asked this before, but now that we've decided on a definite "CAN
FD" format - can the flags fit in the 32-bit value before the CAN ID? If CAN
FD has no RTR or ERR flags, could BRS and ESI replace them? In their current
spot, there is more room for expansion, so I can also see merits to keeping
them there.
You are receiving this mail because:
- You are watching all bug changes.