lkml.org 
[lkml]   [2020]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] firewire: firewire-cdev.h: Avoid the use of one-element array
Date

NACK!

Please, stop doing this. You clearly don't know what you're doing.
You're just blindly copying/pasting all this. The subject line
has nothing to do with what the patch does and we don't want
any of these transformations in UAPI for now.

As I already said here:
https://lore.kernel.org/lkml/90b2c9f3-cc2b-b2e6-51ef-998d2f79123a@embeddedor.com/

start with drivers/staging/ and get hang of the kernel development
process, first. This is a great source, I encourage you to read it
thoroughly:
https://kernelnewbies.org/Outreachyfirstpatch

If you want to land your first kernel patch, blindly copying/pasting
stuff without actually paying attention to what you're doing, is
certainly not the best strategy and you won't start with the right
foot in terms of your reputation. Stop this and do things right from
the beginning.

--
Gustavo

On 7/29/20 22:27, Qianli Zhao wrote:
> From: Qianli Zhao <zhaoqianli@xiaomi.com>
>
> There is a regular need in the kernel to provide a way to declare having a
> dynamically sized set of trailing elements in a structure. Kernel code should
> always use “flexible array members”[1] for these cases. The older style of
> one-element or zero-length arrays should no longer be used[2].
>
> [1] https://en.wikipedia.org/wiki/Flexible_array_member
> [2] https://github.com/KSPP/linux/issues/21
>
> Signed-off-by: Qianli Zhao <zhaoqianli@xiaomi.com>
> ---
> include/uapi/linux/firewire-cdev.h | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/include/uapi/linux/firewire-cdev.h b/include/uapi/linux/firewire-cdev.h
> index 7e5b5c1..487de87f 100644
> --- a/include/uapi/linux/firewire-cdev.h
> +++ b/include/uapi/linux/firewire-cdev.h
> @@ -118,7 +118,7 @@ struct fw_cdev_event_response {
> __u32 type;
> __u32 rcode;
> __u32 length;
> - __u32 data[0];
> + __u32 data[];
> };
>
> /**
> @@ -142,7 +142,7 @@ struct fw_cdev_event_request {
> __u64 offset;
> __u32 handle;
> __u32 length;
> - __u32 data[0];
> + __u32 data[];
> };
>
> /**
> @@ -205,7 +205,7 @@ struct fw_cdev_event_request2 {
> __u32 generation;
> __u32 handle;
> __u32 length;
> - __u32 data[0];
> + __u32 data[];
> };
>
> /**
> @@ -344,7 +344,7 @@ struct fw_cdev_event_iso_resource {
> * @data: Incoming data
> *
> * If @type is %FW_CDEV_EVENT_PHY_PACKET_SENT, @length is 0 and @data empty,
> - * except in case of a ping packet: Then, @length is 4, and @data[0] is the
> + * except in case of a ping packet: Then, @length is 4, and @data[] is the
> * ping time in 49.152MHz clocks if @rcode is %RCODE_COMPLETE.
> *
> * If @type is %FW_CDEV_EVENT_PHY_PACKET_RECEIVED, @length is 8 and @data
> @@ -355,7 +355,7 @@ struct fw_cdev_event_phy_packet {
> __u32 type;
> __u32 rcode;
> __u32 length;
> - __u32 data[0];
> + __u32 data[];
> };
>
> /**
>

\
 
 \ /
  Last update: 2020-07-30 15:33    [W:0.041 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site