Remove commented out code.

Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
 include/linux/sctp.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/linux/sctp.h b/include/linux/sctp.h
index 836a7e200f39..812011d8b67e 100644
--- a/include/linux/sctp.h
+++ b/include/linux/sctp.h
@@ -222,7 +222,6 @@ struct sctp_datahdr {
 	__be16 stream;
 	__be16 ssn;
 	__u32 ppid;
-	/* __u8  payload[]; */
 };
 
 struct sctp_data_chunk {
-- 
2.48.1

On 2/11/2025 11:20 AM, Thorsten Blum wrote:
> Remove commented out code.
> 
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
>   include/linux/sctp.h | 1 -
>   1 file changed, 1 deletion(-)
> 
> diff --git a/include/linux/sctp.h b/include/linux/sctp.h
> index 836a7e200f39..812011d8b67e 100644
> --- a/include/linux/sctp.h
> +++ b/include/linux/sctp.h
> @@ -222,7 +222,6 @@ struct sctp_datahdr {
>   	__be16 stream;
>   	__be16 ssn;
>   	__u32 ppid;
> -	/* __u8  payload[]; */
>   };
>   
>   struct sctp_data_chunk {

Hi Thorsten

I don't think we want to remove that piece of code, please refer
to the discussion under the link:

https://lore.kernel.org/netdev/cover.1681917361.git.lucien.xin@gmail.com/

Thanks

On 11. Feb 2025, at 11:49, Mateusz Polchlopek wrote:
> On 2/11/2025 11:20 AM, Thorsten Blum wrote:
>> Remove commented out code.
>> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
>> ---
>>  include/linux/sctp.h | 1 -
>>  1 file changed, 1 deletion(-)
>> diff --git a/include/linux/sctp.h b/include/linux/sctp.h
>> index 836a7e200f39..812011d8b67e 100644
>> --- a/include/linux/sctp.h
>> +++ b/include/linux/sctp.h
>> @@ -222,7 +222,6 @@ struct sctp_datahdr {
>>   __be16 stream;
>>   __be16 ssn;
>>   __u32 ppid;
>> - /* __u8  payload[]; */
>>  };
>>    struct sctp_data_chunk {
> 
> Hi Thorsten
> 
> I don't think we want to remove that piece of code, please refer
> to the discussion under the link:
> 
> https://lore.kernel.org/netdev/cover.1681917361.git.lucien.xin@gmail.com/

Hm, the commit message (dbda0fba7a14) says payload was deleted because
"the member is not even used anywhere," but it was just commented out.
In the cover letter it then explains that "deleted" actually means
"commented out."

However, I can't follow the reasoning in the cover letter either:

"Note that instead of completely deleting it, we just leave it as a
comment in the struct, signalling to the reader that we do expect
such variable parameters over there, as Marcelo suggested."

Where do I find Marcelo's suggestion and the "variable parameters over
there?"

Thanks,
Thorsten

On 2/11/2025 12:17 PM, Thorsten Blum wrote:
> On 11. Feb 2025, at 11:49, Mateusz Polchlopek wrote:
>> On 2/11/2025 11:20 AM, Thorsten Blum wrote:
>>> Remove commented out code.
>>> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
>>> ---
>>>   include/linux/sctp.h | 1 -
>>>   1 file changed, 1 deletion(-)
>>> diff --git a/include/linux/sctp.h b/include/linux/sctp.h
>>> index 836a7e200f39..812011d8b67e 100644
>>> --- a/include/linux/sctp.h
>>> +++ b/include/linux/sctp.h
>>> @@ -222,7 +222,6 @@ struct sctp_datahdr {
>>>    __be16 stream;
>>>    __be16 ssn;
>>>    __u32 ppid;
>>> - /* __u8  payload[]; */
>>>   };
>>>     struct sctp_data_chunk {
>>
>> Hi Thorsten
>>
>> I don't think we want to remove that piece of code, please refer
>> to the discussion under the link:
>>
>> https://lore.kernel.org/netdev/cover.1681917361.git.lucien.xin@gmail.com/
> 
> Hm, the commit message (dbda0fba7a14) says payload was deleted because
> "the member is not even used anywhere," but it was just commented out.
> In the cover letter it then explains that "deleted" actually means
> "commented out."
> 
> However, I can't follow the reasoning in the cover letter either:
> 
> "Note that instead of completely deleting it, we just leave it as a
> comment in the struct, signalling to the reader that we do expect
> such variable parameters over there, as Marcelo suggested."
> 
> Where do I find Marcelo's suggestion and the "variable parameters over
> there?"
> 

That's good question, I can't find the Marcelo suggestion that author
mention. It's hard to find without links to previous series or
discussion :/

I guess it should be also commented by maintainers, I see that in the
Xin's thread Kuba also commented change with commenting out instead
of removing code. Let's wait

> Thanks,
> Thorsten

On Tue, 11 Feb 2025 12:33:57 +0100 Mateusz Polchlopek wrote:
> >> I don't think we want to remove that piece of code, please refer
> >> to the discussion under the link:
> >>
> >> https://lore.kernel.org/netdev/cover.1681917361.git.lucien.xin@gmail.com/  
> > 
> > Hm, the commit message (dbda0fba7a14) says payload was deleted because
> > "the member is not even used anywhere," but it was just commented out.
> > In the cover letter it then explains that "deleted" actually means
> > "commented out."
> > 
> > However, I can't follow the reasoning in the cover letter either:
> > 
> > "Note that instead of completely deleting it, we just leave it as a
> > comment in the struct, signalling to the reader that we do expect
> > such variable parameters over there, as Marcelo suggested."
> > 
> > Where do I find Marcelo's suggestion and the "variable parameters over
> > there?"
> >   
> 
> That's good question, I can't find the Marcelo suggestion that author
> mention. It's hard to find without links to previous series or
> discussion :/
> 
> I guess it should be also commented by maintainers, I see that in the
> Xin's thread Kuba also commented change with commenting out instead
> of removing code. Let's wait

In the linked thread the point was to document what struct will be next
in memory. Here we'd be leaving an array of u8s which isn't very
informative. I see there's precedent in this file, but I vote we just
delete the line.
-- 
pw-bot: cr

Hi Jakub,

> On 13. Feb 2025, at 04:57, Jakub Kicinski wrote:
> On Tue, 11 Feb 2025 12:33:57 +0100 Mateusz Polchlopek wrote:
>>>> I don't think we want to remove that piece of code, please refer
>>>> to the discussion under the link:
>>>> 
>>>> https://lore.kernel.org/netdev/cover.1681917361.git.lucien.xin@gmail.com/  
>>> 
>>> Hm, the commit message (dbda0fba7a14) says payload was deleted because
>>> "the member is not even used anywhere," but it was just commented out.
>>> In the cover letter it then explains that "deleted" actually means
>>> "commented out."
>>> 
>>> However, I can't follow the reasoning in the cover letter either:
>>> 
>>> "Note that instead of completely deleting it, we just leave it as a
>>> comment in the struct, signalling to the reader that we do expect
>>> such variable parameters over there, as Marcelo suggested."
>>> 
>>> Where do I find Marcelo's suggestion and the "variable parameters over
>>> there?"
>>> 
>> 
>> That's good question, I can't find the Marcelo suggestion that author
>> mention. It's hard to find without links to previous series or
>> discussion :/
>> 
>> I guess it should be also commented by maintainers, I see that in the
>> Xin's thread Kuba also commented change with commenting out instead
>> of removing code. Let's wait
> 
> In the linked thread the point was to document what struct will be next
> in memory. Here we'd be leaving an array of u8s which isn't very
> informative. I see there's precedent in this file, but I vote we just
> delete the line.

This patch deletes the line and I'm wondering why the "cr"?

Were you referring to this patch maybe?
https://lore.kernel.org/r/20250114215439.916207-3-thorsten.blum@linux.dev/

Should both payload fields just be deleted since they're not used?

Thanks,
Thorsten

On 2/13/2025 11:49 AM, Thorsten Blum wrote:
> Hi Jakub,
> 
>> On 13. Feb 2025, at 04:57, Jakub Kicinski wrote:
>> On Tue, 11 Feb 2025 12:33:57 +0100 Mateusz Polchlopek wrote:
>>>>> I don't think we want to remove that piece of code, please refer
>>>>> to the discussion under the link:
>>>>>
>>>>> https://lore.kernel.org/netdev/cover.1681917361.git.lucien.xin@gmail.com/
>>>>
>>>> Hm, the commit message (dbda0fba7a14) says payload was deleted because
>>>> "the member is not even used anywhere," but it was just commented out.
>>>> In the cover letter it then explains that "deleted" actually means
>>>> "commented out."
>>>>
>>>> However, I can't follow the reasoning in the cover letter either:
>>>>
>>>> "Note that instead of completely deleting it, we just leave it as a
>>>> comment in the struct, signalling to the reader that we do expect
>>>> such variable parameters over there, as Marcelo suggested."
>>>>
>>>> Where do I find Marcelo's suggestion and the "variable parameters over
>>>> there?"
>>>>
>>>
>>> That's good question, I can't find the Marcelo suggestion that author
>>> mention. It's hard to find without links to previous series or
>>> discussion :/
>>>
>>> I guess it should be also commented by maintainers, I see that in the
>>> Xin's thread Kuba also commented change with commenting out instead
>>> of removing code. Let's wait
>>
>> In the linked thread the point was to document what struct will be next
>> in memory. Here we'd be leaving an array of u8s which isn't very
>> informative. I see there's precedent in this file, but I vote we just
>> delete the line.
> 
> This patch deletes the line and I'm wondering why the "cr"?
> 
> Were you referring to this patch maybe?
> https://lore.kernel.org/r/20250114215439.916207-3-thorsten.blum@linux.dev/
> 
> Should both payload fields just be deleted since they're not used?
> 
> Thanks,
> Thorsten

Going further I see that in this file there are more fields in
structures that are just commented out, like:

struct sctp_fwdtsn_hdr {
         __be32 new_cum_tsn;
         /* struct sctp_fwdtsn_skip skip[]; */
};

or

struct sctp_sackhdr {
         __be32 cum_tsn_ack;
         __be32 a_rwnd;
         __be16 num_gap_ack_blocks;
         __be16 num_dup_tsns;
         /* union sctp_sack_variable variable[]; */
};

Does it make sense to do the cleanup of the whole header in this
patch ?

Thanks

On Thu, 13 Feb 2025 11:49:45 +0100 Thorsten Blum wrote:
> > In the linked thread the point was to document what struct will be next
> > in memory. Here we'd be leaving an array of u8s which isn't very
> > informative. I see there's precedent in this file, but I vote we just
> > delete the line.  
> 
> This patch deletes the line and I'm wondering why the "cr"?

My bad! Misread the diff.