Comment # 61
on bug 12687
from Oliver Hartkopp
(In reply to Michael Mann from comment #59)
> (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.
SocketCAN developers know about struct can_frame and struct canfd_frame. IMO it
makes sense to preserve these structures in the display of the entire PDU which
is shown at the bottom of the Wireshark application window. The struct
canfd_frame is fixed since Linux 3.6 and it can't be excluded that CAN FD
frames might contain Error Messages in the future.
Therefore I won't recommend to do such kind of improvement.
You are receiving this mail because:
- You are watching all bug changes.
