On Tuesday 12 January 2010 14:19, you wrote:
> Matthias Fuchs wrote:
> > On Monday 11 January 2010 21:10, Wolfgang Grandegger wrote:
> >> We are close, just a few more issues.
> > Uff :-)
> >
> >>> +struct header_msg {
> >>> + __u8 len; /* len is always the total message length in 32bit words */
> >>> + __u8 cmd;
> >>> + __u8 rsvd[2];
> >>> +};
> >> Please use just one type set. Either u8 or __u8 but not both. The same
> >> for __u32, __le32, etc.
> > Good point. Marc invented some versions before to use __le32 instead of
> > u32 in these device structures.
> > As far as I understand this should signal that these are some kind
> > of exchange types (typically with userspace programs or in this case
> > a device).
>
> Exchange with a device?
That was my personal interpretation.
>
> > I am using __ types for all structures that are exchanged with the hardware.
> > All other datatypes stay in the kernel.
> >
> > So what's correct?
>
> My understanding is that the types prefixed with "__" are for header
> files shared with user space. For the kernel we should use u8 or uint8_t
> and friends. Obviously, there is no le32 type - don't asked me why -
> therefore just keep __le32. See for example:
>
> http://lxr.linux.no/#linux+v2.6.32/drivers/scsi/aacraid/aacraid.h
Ok, will do so: u8, 32, __le32
>
> [snip]
> >>> + * The IDADD message takes up to ESD_MAX_ID_SEGMENT 32 bit
> >>> + * bitmasks = 2048 bits. A cleared bit disables reception
> >>> + * of the corresponding CAN identifier.
> >>> + * The next bitmask value following the CAN 2.0A
> >>> + * bits is used to disable reception of extended CAN frames
> >>> + * at all.
> >>> + */
> >>> + msg.msg.hdr.cmd = CMD_IDADD;
> >>> + msg.msg.hdr.len = 1 + ESD_MAX_ID_SEGMENT + 1;
> >> msg.msg.hdr.len = ESD_MAX_ID_SEGMENT + 2;
> >>
> >> Please.
> > Ok, this was for readability: 1 (msg header) + ESD_MAX_.... (for 2.0a IDs)
> > and
> > + 1 (for 2.0b ID range). But you are rigth it looks a little bit curious.
>
> Ah, that was really obvious ;-).
>
> > I will change it and add some more comments about how the device's ID filter
> > is configured.
>
> Good.
>
> Wolfgang.
>
>
Matthias
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
