| Message ID | 20210729022053.134453-5-jk@codeconstruct.com.au (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 60fc63981693f807baa0e404104dedea0e8b4e61 |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | Add Management Component Transport Protocol support | expand |
| Context | Check | Description |
|---|---|---|
| netdev/cover_letter | success | Link |
| netdev/fixes_present | success | Link |
| netdev/patch_count | success | Link |
| netdev/tree_selection | success | Clearly marked for net-next |
| netdev/subject_prefix | success | Link |
| netdev/cc_maintainers | success | CCed 1 of 1 maintainers |
| netdev/source_inline | success | Was 0 now: 0 |
| netdev/verify_signedoff | success | Link |
| netdev/module_param | success | Was 0 now: 0 |
| netdev/build_32bit | success | Errors and warnings before: 0 this patch: 0 |
| netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
| netdev/verify_fixes | success | Link |
| netdev/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 28 lines checked |
| netdev/build_allmodconfig_warn | success | Errors and warnings before: 0 this patch: 0 |
| netdev/header_inline | success | Link |
On Thu, Jul 29, 2021 at 10:20:42AM +0800, Jeremy Kerr wrote: > This change introduces the user-visible MCTP header, containing the > protocol-specific addressing definitions. [...] > --- a/include/uapi/linux/mctp.h > +++ b/include/uapi/linux/mctp.h > @@ -9,7 +9,28 @@ > #ifndef __UAPI_MCTP_H > #define __UAPI_MCTP_H > > +#include <linux/types.h> > + > +typedef __u8 mctp_eid_t; > + > +struct mctp_addr { > + mctp_eid_t s_addr; > +}; > + > struct sockaddr_mctp { > + unsigned short int smctp_family; This gap makes the size of struct sockaddr_mctp 2 bytes less at least on m68k, are you fine with that? > + int smctp_network; > + struct mctp_addr smctp_addr; > + __u8 smctp_type; > + __u8 smctp_tag; > };
Hi Eugene, Thanks for taking a look at these! > > +typedef __u8 mctp_eid_t; > > + > > +struct mctp_addr { > > + mctp_eid_t s_addr; > > +}; > > + > > struct sockaddr_mctp { > > + unsigned short int smctp_family; > > This gap makes the size of struct sockaddr_mctp 2 bytes less at least > on m68k, are you fine with that? Yep, that's OK from the protocol implementation side; this layout better matches the "hierarchy" of the MCTP addressing. If we go for optimal packing, the order of the members makes somewhat less sense. We could add padding members, but I'm not sure that's worth it... I noticed a few other protocol implementations doing similar things, so assume it isn't an issue - it's all arch-specific ABI anyway, right? > > + int smctp_network; > > + struct mctp_addr smctp_addr; > > + __u8 smctp_type; > > + __u8 smctp_tag; > > }; Cheers, Jeremy
On Fri, Oct 15, 2021 at 12:32 AM Eugene Syromiatnikov <esyr@redhat.com> wrote: > On Thu, Jul 29, 2021 at 10:20:42AM +0800, Jeremy Kerr wrote: > > This change introduces the user-visible MCTP header, containing the > > protocol-specific addressing definitions. > > [...] > > > --- a/include/uapi/linux/mctp.h > > +++ b/include/uapi/linux/mctp.h > > @@ -9,7 +9,28 @@ > > #ifndef __UAPI_MCTP_H > > #define __UAPI_MCTP_H > > > > +#include <linux/types.h> > > + > > +typedef __u8 mctp_eid_t; > > + > > +struct mctp_addr { > > + mctp_eid_t s_addr; > > +}; > > + > > struct sockaddr_mctp { > > + unsigned short int smctp_family; > > This gap makes the size of struct sockaddr_mctp 2 bytes less at least > on m68k, are you fine with that? > > > + int smctp_network; > > + struct mctp_addr smctp_addr; > > + __u8 smctp_type; > > + __u8 smctp_tag; And it may be wise to add 1 byte of explicit padding here? Or is there a good reason not to do so? > > }; Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Thu, Jul 29, 2021 at 10:20:42AM +0800, Jeremy Kerr wrote: > struct sockaddr_mctp { > + unsigned short int smctp_family; > + int smctp_network; struct mctp_skb_cb.net (as well as struct mctp_dev.net) are unsigned, is it intentional that this field (along with struct mctp_sock.bind_net) differs in signedness?
Hi Eugene, > On Thu, Jul 29, 2021 at 10:20:42AM +0800, Jeremy Kerr wrote: > > struct sockaddr_mctp { > > + unsigned short int smctp_family; > > + int smctp_network; > > struct mctp_skb_cb.net (as well as struct mctp_dev.net) are unsigned, > is it intentional that this field (along with struct > mctp_sock.bind_net) differs in signedness? No, that's not intentional - I'll submit a patch to unify those. Thanks for the review. Cheers, Jeremy
diff --git a/include/uapi/linux/mctp.h b/include/uapi/linux/mctp.h index 2640a589c14c..52b54d13f385 100644 --- a/include/uapi/linux/mctp.h +++ b/include/uapi/linux/mctp.h @@ -9,7 +9,28 @@ #ifndef __UAPI_MCTP_H #define __UAPI_MCTP_H +#include <linux/types.h> + +typedef __u8 mctp_eid_t; + +struct mctp_addr { + mctp_eid_t s_addr; +}; + struct sockaddr_mctp { + unsigned short int smctp_family; + int smctp_network; + struct mctp_addr smctp_addr; + __u8 smctp_type; + __u8 smctp_tag; }; +#define MCTP_NET_ANY 0x0 + +#define MCTP_ADDR_NULL 0x00 +#define MCTP_ADDR_ANY 0xff + +#define MCTP_TAG_MASK 0x07 +#define MCTP_TAG_OWNER 0x08 + #endif /* __UAPI_MCTP_H */
This change introduces the user-visible MCTP header, containing the protocol-specific addressing definitions. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> --- v2: - include MCTP_ADDR_NULL and MCTP_TAG_* definitions v3: - don't use GENMASK/BIT in uapi --- include/uapi/linux/mctp.h | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)