From: Phil Sutter <phil@nwl.cc>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: David Miller <davem@davemloft.net>,
Xin Long <lucien.xin@gmail.com>,
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
netdev@vger.kernel.org, linux-sctp@vger.kernel.org
Subject: Re: [PATCH v3 1/3] sctp: Export struct sctp_info to userspace
Date: Thu, 04 Aug 2016 14:40:21 +0000 [thread overview]
Message-ID: <20160804144021.GD8988@orbyte.nwl.cc> (raw)
In-Reply-To: <20160804133329.GA11579@hmsreliant.think-freely.org>
On Thu, Aug 04, 2016 at 09:33:29AM -0400, Neil Horman wrote:
> On Thu, Aug 04, 2016 at 12:11:55PM +0200, Phil Sutter wrote:
> > This is required to correctly interpret INET_DIAG_INFO messages exported
> > by sctp_diag module.
> >
> > Signed-off-by: Phil Sutter <phil@nwl.cc>
> > ---
> > include/linux/sctp.h | 64 -----------------------------------------------
> > include/uapi/linux/sctp.h | 64 +++++++++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 64 insertions(+), 64 deletions(-)
> >
> > diff --git a/include/linux/sctp.h b/include/linux/sctp.h
> > index de1f64318fc4e..fcb4c36461732 100644
> > --- a/include/linux/sctp.h
> > +++ b/include/linux/sctp.h
> > @@ -705,70 +705,6 @@ typedef struct sctp_auth_chunk {
> > sctp_authhdr_t auth_hdr;
> > } __packed sctp_auth_chunk_t;
> >
> > -struct sctp_info {
> > - __u32 sctpi_tag;
> > - __u32 sctpi_state;
> > - __u32 sctpi_rwnd;
> > - __u16 sctpi_unackdata;
> > - __u16 sctpi_penddata;
> > - __u16 sctpi_instrms;
> > - __u16 sctpi_outstrms;
> > - __u32 sctpi_fragmentation_point;
> > - __u32 sctpi_inqueue;
> > - __u32 sctpi_outqueue;
> > - __u32 sctpi_overall_error;
> > - __u32 sctpi_max_burst;
> > - __u32 sctpi_maxseg;
> > - __u32 sctpi_peer_rwnd;
> > - __u32 sctpi_peer_tag;
> > - __u8 sctpi_peer_capable;
> > - __u8 sctpi_peer_sack;
> > - __u16 __reserved1;
> > -
> > - /* assoc status info */
> > - __u64 sctpi_isacks;
> > - __u64 sctpi_osacks;
> > - __u64 sctpi_opackets;
> > - __u64 sctpi_ipackets;
> > - __u64 sctpi_rtxchunks;
> > - __u64 sctpi_outofseqtsns;
> > - __u64 sctpi_idupchunks;
> > - __u64 sctpi_gapcnt;
> > - __u64 sctpi_ouodchunks;
> > - __u64 sctpi_iuodchunks;
> > - __u64 sctpi_oodchunks;
> > - __u64 sctpi_iodchunks;
> > - __u64 sctpi_octrlchunks;
> > - __u64 sctpi_ictrlchunks;
> > -
> > - /* primary transport info */
> > - struct sockaddr_storage sctpi_p_address;
> > - __s32 sctpi_p_state;
> > - __u32 sctpi_p_cwnd;
> > - __u32 sctpi_p_srtt;
> > - __u32 sctpi_p_rto;
> > - __u32 sctpi_p_hbinterval;
> > - __u32 sctpi_p_pathmaxrxt;
> > - __u32 sctpi_p_sackdelay;
> > - __u32 sctpi_p_sackfreq;
> > - __u32 sctpi_p_ssthresh;
> > - __u32 sctpi_p_partial_bytes_acked;
> > - __u32 sctpi_p_flight_size;
> > - __u16 sctpi_p_error;
> > - __u16 __reserved2;
> > -
> > - /* sctp sock info */
> > - __u32 sctpi_s_autoclose;
> > - __u32 sctpi_s_adaptation_ind;
> > - __u32 sctpi_s_pd_point;
> > - __u8 sctpi_s_nodelay;
> > - __u8 sctpi_s_disable_fragments;
> > - __u8 sctpi_s_v4mapped;
> > - __u8 sctpi_s_frag_interleave;
> > - __u32 sctpi_s_type;
> > - __u32 __reserved3;
> > -};
> > -
> > struct sctp_infox {
> > struct sctp_info *sctpinfo;
> > struct sctp_association *asoc;
> > diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
> > index d304f4c9792c4..a406adcc0793e 100644
> > --- a/include/uapi/linux/sctp.h
> > +++ b/include/uapi/linux/sctp.h
> > @@ -944,4 +944,68 @@ struct sctp_default_prinfo {
> > __u16 pr_policy;
> > };
> >
> > +struct sctp_info {
> > + __u32 sctpi_tag;
> > + __u32 sctpi_state;
> > + __u32 sctpi_rwnd;
> > + __u16 sctpi_unackdata;
> > + __u16 sctpi_penddata;
> > + __u16 sctpi_instrms;
> > + __u16 sctpi_outstrms;
> > + __u32 sctpi_fragmentation_point;
> > + __u32 sctpi_inqueue;
> > + __u32 sctpi_outqueue;
> > + __u32 sctpi_overall_error;
> > + __u32 sctpi_max_burst;
> > + __u32 sctpi_maxseg;
> > + __u32 sctpi_peer_rwnd;
> > + __u32 sctpi_peer_tag;
> > + __u8 sctpi_peer_capable;
> > + __u8 sctpi_peer_sack;
> > + __u16 __reserved1;
> > +
> > + /* assoc status info */
> > + __u64 sctpi_isacks;
> > + __u64 sctpi_osacks;
> > + __u64 sctpi_opackets;
> > + __u64 sctpi_ipackets;
> > + __u64 sctpi_rtxchunks;
> > + __u64 sctpi_outofseqtsns;
> > + __u64 sctpi_idupchunks;
> > + __u64 sctpi_gapcnt;
> > + __u64 sctpi_ouodchunks;
> > + __u64 sctpi_iuodchunks;
> > + __u64 sctpi_oodchunks;
> > + __u64 sctpi_iodchunks;
> > + __u64 sctpi_octrlchunks;
> > + __u64 sctpi_ictrlchunks;
> > +
> > + /* primary transport info */
> > + struct sockaddr_storage sctpi_p_address;
> > + __s32 sctpi_p_state;
> > + __u32 sctpi_p_cwnd;
> > + __u32 sctpi_p_srtt;
> > + __u32 sctpi_p_rto;
> > + __u32 sctpi_p_hbinterval;
> > + __u32 sctpi_p_pathmaxrxt;
> > + __u32 sctpi_p_sackdelay;
> > + __u32 sctpi_p_sackfreq;
> > + __u32 sctpi_p_ssthresh;
> > + __u32 sctpi_p_partial_bytes_acked;
> > + __u32 sctpi_p_flight_size;
> > + __u16 sctpi_p_error;
> > + __u16 __reserved2;
> > +
> > + /* sctp sock info */
> > + __u32 sctpi_s_autoclose;
> > + __u32 sctpi_s_adaptation_ind;
> > + __u32 sctpi_s_pd_point;
> > + __u8 sctpi_s_nodelay;
> > + __u8 sctpi_s_disable_fragments;
> > + __u8 sctpi_s_v4mapped;
> > + __u8 sctpi_s_frag_interleave;
> > + __u32 sctpi_s_type;
> > + __u32 __reserved3;
> > +};
> > +
> If you export these, shouldn't they be converted to the corresponding
> uint<size>_t variants?
As mentioned earlier, uapi headers using the __u* types seems not
uncommon. Another aspect is consistency, these types are used throughout
the whole file already, so if I should change them, they all should be
changed. And assuming uapi/linux/tcp.h being a good example: struct
tcp_info uses them also.
Cheers, Phil
WARNING: multiple messages have this Message-ID (diff)
From: Phil Sutter <phil@nwl.cc>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: David Miller <davem@davemloft.net>,
Xin Long <lucien.xin@gmail.com>,
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
netdev@vger.kernel.org, linux-sctp@vger.kernel.org
Subject: Re: [PATCH v3 1/3] sctp: Export struct sctp_info to userspace
Date: Thu, 4 Aug 2016 16:40:21 +0200 [thread overview]
Message-ID: <20160804144021.GD8988@orbyte.nwl.cc> (raw)
In-Reply-To: <20160804133329.GA11579@hmsreliant.think-freely.org>
On Thu, Aug 04, 2016 at 09:33:29AM -0400, Neil Horman wrote:
> On Thu, Aug 04, 2016 at 12:11:55PM +0200, Phil Sutter wrote:
> > This is required to correctly interpret INET_DIAG_INFO messages exported
> > by sctp_diag module.
> >
> > Signed-off-by: Phil Sutter <phil@nwl.cc>
> > ---
> > include/linux/sctp.h | 64 -----------------------------------------------
> > include/uapi/linux/sctp.h | 64 +++++++++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 64 insertions(+), 64 deletions(-)
> >
> > diff --git a/include/linux/sctp.h b/include/linux/sctp.h
> > index de1f64318fc4e..fcb4c36461732 100644
> > --- a/include/linux/sctp.h
> > +++ b/include/linux/sctp.h
> > @@ -705,70 +705,6 @@ typedef struct sctp_auth_chunk {
> > sctp_authhdr_t auth_hdr;
> > } __packed sctp_auth_chunk_t;
> >
> > -struct sctp_info {
> > - __u32 sctpi_tag;
> > - __u32 sctpi_state;
> > - __u32 sctpi_rwnd;
> > - __u16 sctpi_unackdata;
> > - __u16 sctpi_penddata;
> > - __u16 sctpi_instrms;
> > - __u16 sctpi_outstrms;
> > - __u32 sctpi_fragmentation_point;
> > - __u32 sctpi_inqueue;
> > - __u32 sctpi_outqueue;
> > - __u32 sctpi_overall_error;
> > - __u32 sctpi_max_burst;
> > - __u32 sctpi_maxseg;
> > - __u32 sctpi_peer_rwnd;
> > - __u32 sctpi_peer_tag;
> > - __u8 sctpi_peer_capable;
> > - __u8 sctpi_peer_sack;
> > - __u16 __reserved1;
> > -
> > - /* assoc status info */
> > - __u64 sctpi_isacks;
> > - __u64 sctpi_osacks;
> > - __u64 sctpi_opackets;
> > - __u64 sctpi_ipackets;
> > - __u64 sctpi_rtxchunks;
> > - __u64 sctpi_outofseqtsns;
> > - __u64 sctpi_idupchunks;
> > - __u64 sctpi_gapcnt;
> > - __u64 sctpi_ouodchunks;
> > - __u64 sctpi_iuodchunks;
> > - __u64 sctpi_oodchunks;
> > - __u64 sctpi_iodchunks;
> > - __u64 sctpi_octrlchunks;
> > - __u64 sctpi_ictrlchunks;
> > -
> > - /* primary transport info */
> > - struct sockaddr_storage sctpi_p_address;
> > - __s32 sctpi_p_state;
> > - __u32 sctpi_p_cwnd;
> > - __u32 sctpi_p_srtt;
> > - __u32 sctpi_p_rto;
> > - __u32 sctpi_p_hbinterval;
> > - __u32 sctpi_p_pathmaxrxt;
> > - __u32 sctpi_p_sackdelay;
> > - __u32 sctpi_p_sackfreq;
> > - __u32 sctpi_p_ssthresh;
> > - __u32 sctpi_p_partial_bytes_acked;
> > - __u32 sctpi_p_flight_size;
> > - __u16 sctpi_p_error;
> > - __u16 __reserved2;
> > -
> > - /* sctp sock info */
> > - __u32 sctpi_s_autoclose;
> > - __u32 sctpi_s_adaptation_ind;
> > - __u32 sctpi_s_pd_point;
> > - __u8 sctpi_s_nodelay;
> > - __u8 sctpi_s_disable_fragments;
> > - __u8 sctpi_s_v4mapped;
> > - __u8 sctpi_s_frag_interleave;
> > - __u32 sctpi_s_type;
> > - __u32 __reserved3;
> > -};
> > -
> > struct sctp_infox {
> > struct sctp_info *sctpinfo;
> > struct sctp_association *asoc;
> > diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
> > index d304f4c9792c4..a406adcc0793e 100644
> > --- a/include/uapi/linux/sctp.h
> > +++ b/include/uapi/linux/sctp.h
> > @@ -944,4 +944,68 @@ struct sctp_default_prinfo {
> > __u16 pr_policy;
> > };
> >
> > +struct sctp_info {
> > + __u32 sctpi_tag;
> > + __u32 sctpi_state;
> > + __u32 sctpi_rwnd;
> > + __u16 sctpi_unackdata;
> > + __u16 sctpi_penddata;
> > + __u16 sctpi_instrms;
> > + __u16 sctpi_outstrms;
> > + __u32 sctpi_fragmentation_point;
> > + __u32 sctpi_inqueue;
> > + __u32 sctpi_outqueue;
> > + __u32 sctpi_overall_error;
> > + __u32 sctpi_max_burst;
> > + __u32 sctpi_maxseg;
> > + __u32 sctpi_peer_rwnd;
> > + __u32 sctpi_peer_tag;
> > + __u8 sctpi_peer_capable;
> > + __u8 sctpi_peer_sack;
> > + __u16 __reserved1;
> > +
> > + /* assoc status info */
> > + __u64 sctpi_isacks;
> > + __u64 sctpi_osacks;
> > + __u64 sctpi_opackets;
> > + __u64 sctpi_ipackets;
> > + __u64 sctpi_rtxchunks;
> > + __u64 sctpi_outofseqtsns;
> > + __u64 sctpi_idupchunks;
> > + __u64 sctpi_gapcnt;
> > + __u64 sctpi_ouodchunks;
> > + __u64 sctpi_iuodchunks;
> > + __u64 sctpi_oodchunks;
> > + __u64 sctpi_iodchunks;
> > + __u64 sctpi_octrlchunks;
> > + __u64 sctpi_ictrlchunks;
> > +
> > + /* primary transport info */
> > + struct sockaddr_storage sctpi_p_address;
> > + __s32 sctpi_p_state;
> > + __u32 sctpi_p_cwnd;
> > + __u32 sctpi_p_srtt;
> > + __u32 sctpi_p_rto;
> > + __u32 sctpi_p_hbinterval;
> > + __u32 sctpi_p_pathmaxrxt;
> > + __u32 sctpi_p_sackdelay;
> > + __u32 sctpi_p_sackfreq;
> > + __u32 sctpi_p_ssthresh;
> > + __u32 sctpi_p_partial_bytes_acked;
> > + __u32 sctpi_p_flight_size;
> > + __u16 sctpi_p_error;
> > + __u16 __reserved2;
> > +
> > + /* sctp sock info */
> > + __u32 sctpi_s_autoclose;
> > + __u32 sctpi_s_adaptation_ind;
> > + __u32 sctpi_s_pd_point;
> > + __u8 sctpi_s_nodelay;
> > + __u8 sctpi_s_disable_fragments;
> > + __u8 sctpi_s_v4mapped;
> > + __u8 sctpi_s_frag_interleave;
> > + __u32 sctpi_s_type;
> > + __u32 __reserved3;
> > +};
> > +
> If you export these, shouldn't they be converted to the corresponding
> uint<size>_t variants?
As mentioned earlier, uapi headers using the __u* types seems not
uncommon. Another aspect is consistency, these types are used throughout
the whole file already, so if I should change them, they all should be
changed. And assuming uapi/linux/tcp.h being a good example: struct
tcp_info uses them also.
Cheers, Phil
next prev parent reply other threads:[~2016-08-04 14:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-04 10:11 [PATCH v3 0/3] sctp_diag: A bunch of fixes for upcoming 'ss' support Phil Sutter
2016-08-04 10:11 ` Phil Sutter
2016-08-04 10:11 ` [PATCH v3 1/3] sctp: Export struct sctp_info to userspace Phil Sutter
2016-08-04 10:11 ` Phil Sutter
2016-08-04 13:33 ` Neil Horman
2016-08-04 13:33 ` Neil Horman
2016-08-04 14:40 ` Phil Sutter [this message]
2016-08-04 14:40 ` Phil Sutter
2016-08-04 10:11 ` [PATCH v3 2/3] sctp_diag: Fix T3_rtx timer export Phil Sutter
2016-08-04 10:11 ` Phil Sutter
2016-08-04 10:11 ` [PATCH v3 3/3] sctp_diag: Respect ss adding TCPF_CLOSE to idiag_states Phil Sutter
2016-08-04 10:11 ` Phil Sutter
2016-08-04 12:36 ` [PATCH v3 0/3] sctp_diag: A bunch of fixes for upcoming 'ss' support Marcelo Ricardo Leitner
2016-08-04 12:36 ` Marcelo Ricardo Leitner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160804144021.GD8988@orbyte.nwl.cc \
--to=phil@nwl.cc \
--cc=davem@davemloft.net \
--cc=linux-sctp@vger.kernel.org \
--cc=lucien.xin@gmail.com \
--cc=marcelo.leitner@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=nhorman@tuxdriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.