Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1301037 > unrolled thread

[PATCH 09/17] usb: host: ehci-dbg: fix up function definitions

Started by"Geyslan G. Bem" <geyslan@gmail.com>
First post2016-01-04 21:20 +0100
Last post2016-01-05 16:30 +0100
Articles 12 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 09/17] usb: host: ehci-dbg: fix up function definitions "Geyslan G. Bem" <geyslan@gmail.com> - 2016-01-04 21:20 +0100
    Re: [PATCH 09/17] usb: host: ehci-dbg: fix up function definitions Alan Stern <stern@rowland.harvard.edu> - 2016-01-04 22:10 +0100
      Re: [PATCH 09/17] usb: host: ehci-dbg: fix up function definitions "Geyslan G. Bem" <geyslan@gmail.com> - 2016-01-05 00:30 +0100
        Re: [PATCH 09/17] usb: host: ehci-dbg: fix up function definitions Alan Stern <stern@rowland.harvard.edu> - 2016-01-05 16:20 +0100
          Re: [PATCH 09/17] usb: host: ehci-dbg: fix up function definitions Joe Perches <joe@perches.com> - 2016-01-05 16:30 +0100
            Re: [PATCH 09/17] usb: host: ehci-dbg: fix up function definitions "Geyslan G. Bem" <geyslan@gmail.com> - 2016-01-05 16:30 +0100
              Re: [PATCH 09/17] usb: host: ehci-dbg: fix up function definitions "Geyslan G. Bem" <geyslan@gmail.com> - 2016-01-05 16:40 +0100
            Re: [PATCH 09/17] usb: host: ehci-dbg: fix up function definitions Alan Stern <stern@rowland.harvard.edu> - 2016-01-05 17:10 +0100
              Re: [PATCH 09/17] usb: host: ehci-dbg: fix up function definitions Joe Perches <joe@perches.com> - 2016-01-05 17:20 +0100
                Re: [PATCH 09/17] usb: host: ehci-dbg: fix up function definitions Alan Stern <stern@rowland.harvard.edu> - 2016-01-05 17:30 +0100
                  Re: [PATCH 09/17] usb: host: ehci-dbg: fix up function definitions "Geyslan G. Bem" <geyslan@gmail.com> - 2016-01-05 18:10 +0100
          Re: [PATCH 09/17] usb: host: ehci-dbg: fix up function definitions Joe Perches <joe@perches.com> - 2016-01-05 16:30 +0100

#1301037 — [PATCH 09/17] usb: host: ehci-dbg: fix up function definitions

From"Geyslan G. Bem" <geyslan@gmail.com>
Date2016-01-04 21:20 +0100
Subject[PATCH 09/17] usb: host: ehci-dbg: fix up function definitions
Message-ID<qNjLJ-8i4-29@gated-at.bofh.it>
Functions must have the opening brace at the beginning of the next line
and body conforming indentation.

This patch also reduces qh_lines() header definition to two lines.

Signed-off-by: Geyslan G. Bem <geyslan@gmail.com>
---
 drivers/usb/host/ehci-dbg.c | 44 +++++++++++++++++++++++++++++---------------
 1 file changed, 29 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/host/ehci-dbg.c b/drivers/usb/host/ehci-dbg.c
index edae79e..a365d9d 100644
--- a/drivers/usb/host/ehci-dbg.c
+++ b/drivers/usb/host/ehci-dbg.c
@@ -54,7 +54,9 @@ static void dbg_hcs_params(struct ehci_hcd *ehci, char *label)
 }
 #else
 
-static inline void dbg_hcs_params(struct ehci_hcd *ehci, char *label) {}
+static inline void dbg_hcs_params(struct ehci_hcd *ehci, char *label)
+{
+}
 
 #endif
 
@@ -94,7 +96,9 @@ static void dbg_hcc_params(struct ehci_hcd *ehci, char *label)
 }
 #else
 
-static inline void dbg_hcc_params(struct ehci_hcd *ehci, char *label) {}
+static inline void dbg_hcc_params(struct ehci_hcd *ehci, char *label)
+{
+}
 
 #endif
 
@@ -284,23 +288,32 @@ dbg_port_buf(char *buf, unsigned len, const char *label, int port, u32 status)
 #else
 static inline void __maybe_unused
 dbg_qh(char *label, struct ehci_hcd *ehci, struct ehci_qh *qh)
-{}
+{
+}
 
 static inline int __maybe_unused
 dbg_status_buf(char *buf, unsigned len, const char *label, u32 status)
-{ return 0; }
+{
+	return 0;
+}
 
 static inline int __maybe_unused
 dbg_command_buf(char *buf, unsigned len, const char *label, u32 command)
-{ return 0; }
+{
+	return 0;
+}
 
 static inline int __maybe_unused
 dbg_intr_buf(char *buf, unsigned len, const char *label, u32 enable)
-{ return 0; }
+{
+	return 0;
+}
 
 static inline int __maybe_unused
 dbg_port_buf(char *buf, unsigned len, const char *label, int port, u32 status)
-{ return 0; }
+{
+	return 0;
+}
 
 #endif	/* CONFIG_DYNAMIC_DEBUG */
 
@@ -327,8 +340,13 @@ dbg_port_buf(char *buf, unsigned len, const char *label, int port, u32 status)
 
 #ifdef STUB_DEBUG_FILES
 
-static inline void create_debug_files(struct ehci_hcd *bus) { }
-static inline void remove_debug_files(struct ehci_hcd *bus) { }
+static inline void create_debug_files(struct ehci_hcd *bus)
+{
+}
+
+static inline void remove_debug_files(struct ehci_hcd *bus)
+{
+}
 
 #else
 
@@ -404,12 +422,8 @@ static inline char token_mark(struct ehci_hcd *ehci, __hc32 token)
 	return '/';
 }
 
-static void qh_lines(
-	struct ehci_hcd *ehci,
-	struct ehci_qh *qh,
-	char **nextp,
-	unsigned *sizep
-)
+static void qh_lines(struct ehci_hcd *ehci, struct ehci_qh *qh,
+			char **nextp, unsigned *sizep)
 {
 	u32			scratch;
 	u32			hw_curr;
-- 
2.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1301094

FromAlan Stern <stern@rowland.harvard.edu>
Date2016-01-04 22:10 +0100
Message-ID<qNky6-oU-11@gated-at.bofh.it>
In reply to#1301037
On Mon, 4 Jan 2016, Geyslan G. Bem wrote:

> Functions must have the opening brace at the beginning of the next line
> and body conforming indentation.

This isn't necessary if the function is an empty static inline void 
routine.

Alan Stern

> This patch also reduces qh_lines() header definition to two lines.
> 
> Signed-off-by: Geyslan G. Bem <geyslan@gmail.com>
> ---
>  drivers/usb/host/ehci-dbg.c | 44 +++++++++++++++++++++++++++++---------------
>  1 file changed, 29 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/usb/host/ehci-dbg.c b/drivers/usb/host/ehci-dbg.c
> index edae79e..a365d9d 100644
> --- a/drivers/usb/host/ehci-dbg.c
> +++ b/drivers/usb/host/ehci-dbg.c
> @@ -54,7 +54,9 @@ static void dbg_hcs_params(struct ehci_hcd *ehci, char *label)
>  }
>  #else
>  
> -static inline void dbg_hcs_params(struct ehci_hcd *ehci, char *label) {}
> +static inline void dbg_hcs_params(struct ehci_hcd *ehci, char *label)
> +{
> +}
>  
>  #endif
>  
> @@ -94,7 +96,9 @@ static void dbg_hcc_params(struct ehci_hcd *ehci, char *label)
>  }
>  #else
>  
> -static inline void dbg_hcc_params(struct ehci_hcd *ehci, char *label) {}
> +static inline void dbg_hcc_params(struct ehci_hcd *ehci, char *label)
> +{
> +}
>  
>  #endif
>  
> @@ -284,23 +288,32 @@ dbg_port_buf(char *buf, unsigned len, const char *label, int port, u32 status)
>  #else
>  static inline void __maybe_unused
>  dbg_qh(char *label, struct ehci_hcd *ehci, struct ehci_qh *qh)
> -{}
> +{
> +}
>  
>  static inline int __maybe_unused
>  dbg_status_buf(char *buf, unsigned len, const char *label, u32 status)
> -{ return 0; }
> +{
> +	return 0;
> +}
>  
>  static inline int __maybe_unused
>  dbg_command_buf(char *buf, unsigned len, const char *label, u32 command)
> -{ return 0; }
> +{
> +	return 0;
> +}
>  
>  static inline int __maybe_unused
>  dbg_intr_buf(char *buf, unsigned len, const char *label, u32 enable)
> -{ return 0; }
> +{
> +	return 0;
> +}
>  
>  static inline int __maybe_unused
>  dbg_port_buf(char *buf, unsigned len, const char *label, int port, u32 status)
> -{ return 0; }
> +{
> +	return 0;
> +}
>  
>  #endif	/* CONFIG_DYNAMIC_DEBUG */
>  
> @@ -327,8 +340,13 @@ dbg_port_buf(char *buf, unsigned len, const char *label, int port, u32 status)
>  
>  #ifdef STUB_DEBUG_FILES
>  
> -static inline void create_debug_files(struct ehci_hcd *bus) { }
> -static inline void remove_debug_files(struct ehci_hcd *bus) { }
> +static inline void create_debug_files(struct ehci_hcd *bus)
> +{
> +}
> +
> +static inline void remove_debug_files(struct ehci_hcd *bus)
> +{
> +}
>  
>  #else
>  
> @@ -404,12 +422,8 @@ static inline char token_mark(struct ehci_hcd *ehci, __hc32 token)
>  	return '/';
>  }
>  
> -static void qh_lines(
> -	struct ehci_hcd *ehci,
> -	struct ehci_qh *qh,
> -	char **nextp,
> -	unsigned *sizep
> -)
> +static void qh_lines(struct ehci_hcd *ehci, struct ehci_qh *qh,
> +			char **nextp, unsigned *sizep)
>  {
>  	u32			scratch;
>  	u32			hw_curr;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1301189

From"Geyslan G. Bem" <geyslan@gmail.com>
Date2016-01-05 00:30 +0100
Message-ID<qNmJA-1Nj-37@gated-at.bofh.it>
In reply to#1301094
2016-01-04 18:00 GMT-03:00 Alan Stern <stern@rowland.harvard.edu>:
> On Mon, 4 Jan 2016, Geyslan G. Bem wrote:
>
>> Functions must have the opening brace at the beginning of the next line
>> and body conforming indentation.
>
> This isn't necessary if the function is an empty static inline void
> routine.
Ok. It's more related to style. Let's forget it.

>
> Alan Stern
>
>> This patch also reduces qh_lines() header definition to two lines.
>>
>> Signed-off-by: Geyslan G. Bem <geyslan@gmail.com>
>> ---
>>  drivers/usb/host/ehci-dbg.c | 44 +++++++++++++++++++++++++++++---------------
>>  1 file changed, 29 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/usb/host/ehci-dbg.c b/drivers/usb/host/ehci-dbg.c
>> index edae79e..a365d9d 100644
>> --- a/drivers/usb/host/ehci-dbg.c
>> +++ b/drivers/usb/host/ehci-dbg.c
>> @@ -54,7 +54,9 @@ static void dbg_hcs_params(struct ehci_hcd *ehci, char *label)
>>  }
>>  #else
>>
>> -static inline void dbg_hcs_params(struct ehci_hcd *ehci, char *label) {}
>> +static inline void dbg_hcs_params(struct ehci_hcd *ehci, char *label)
>> +{
>> +}
>>
>>  #endif
>>
>> @@ -94,7 +96,9 @@ static void dbg_hcc_params(struct ehci_hcd *ehci, char *label)
>>  }
>>  #else
>>
>> -static inline void dbg_hcc_params(struct ehci_hcd *ehci, char *label) {}
>> +static inline void dbg_hcc_params(struct ehci_hcd *ehci, char *label)
>> +{
>> +}
>>
>>  #endif
>>
>> @@ -284,23 +288,32 @@ dbg_port_buf(char *buf, unsigned len, const char *label, int port, u32 status)
>>  #else
>>  static inline void __maybe_unused
>>  dbg_qh(char *label, struct ehci_hcd *ehci, struct ehci_qh *qh)
>> -{}
>> +{
>> +}
>>
>>  static inline int __maybe_unused
>>  dbg_status_buf(char *buf, unsigned len, const char *label, u32 status)
>> -{ return 0; }
>> +{
>> +     return 0;
>> +}
>>
>>  static inline int __maybe_unused
>>  dbg_command_buf(char *buf, unsigned len, const char *label, u32 command)
>> -{ return 0; }
>> +{
>> +     return 0;
>> +}
>>
>>  static inline int __maybe_unused
>>  dbg_intr_buf(char *buf, unsigned len, const char *label, u32 enable)
>> -{ return 0; }
>> +{
>> +     return 0;
>> +}
>>
>>  static inline int __maybe_unused
>>  dbg_port_buf(char *buf, unsigned len, const char *label, int port, u32 status)
>> -{ return 0; }
>> +{
>> +     return 0;
>> +}
>>
>>  #endif       /* CONFIG_DYNAMIC_DEBUG */
>>
>> @@ -327,8 +340,13 @@ dbg_port_buf(char *buf, unsigned len, const char *label, int port, u32 status)
>>
>>  #ifdef STUB_DEBUG_FILES
>>
>> -static inline void create_debug_files(struct ehci_hcd *bus) { }
>> -static inline void remove_debug_files(struct ehci_hcd *bus) { }
>> +static inline void create_debug_files(struct ehci_hcd *bus)
>> +{
>> +}
>> +
>> +static inline void remove_debug_files(struct ehci_hcd *bus)
>> +{
>> +}
>>
>>  #else
>>
>> @@ -404,12 +422,8 @@ static inline char token_mark(struct ehci_hcd *ehci, __hc32 token)
>>       return '/';
>>  }
>>
>> -static void qh_lines(
>> -     struct ehci_hcd *ehci,
>> -     struct ehci_qh *qh,
>> -     char **nextp,
>> -     unsigned *sizep
>> -)
>> +static void qh_lines(struct ehci_hcd *ehci, struct ehci_qh *qh,
>> +                     char **nextp, unsigned *sizep)
>>  {
>>       u32                     scratch;
>>       u32                     hw_curr;
>>
>
And about that style? Should be done?



-- 
Regards,

Geyslan G. Bem
hackingbits.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1301594

FromAlan Stern <stern@rowland.harvard.edu>
Date2016-01-05 16:20 +0100
Message-ID<qNByW-4zh-3@gated-at.bofh.it>
In reply to#1301189
On Mon, 4 Jan 2016, Geyslan G. Bem wrote:

> >> @@ -404,12 +422,8 @@ static inline char token_mark(struct ehci_hcd *ehci, __hc32 token)
> >>       return '/';
> >>  }
> >>
> >> -static void qh_lines(
> >> -     struct ehci_hcd *ehci,
> >> -     struct ehci_qh *qh,
> >> -     char **nextp,
> >> -     unsigned *sizep
> >> -)
> >> +static void qh_lines(struct ehci_hcd *ehci, struct ehci_qh *qh,
> >> +                     char **nextp, unsigned *sizep)
> >>  {
> >>       u32                     scratch;
> >>       u32                     hw_curr;
> >>
> >
> And about that style? Should be done?

You mean squeezing the function parameters into two lines?  That's 
okay.

However, the style in this file is to indent continuation lines by two
extra tab stops, not to line things up with an open paren on the first
line.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1301599

FromJoe Perches <joe@perches.com>
Date2016-01-05 16:30 +0100
Message-ID<qNBIC-4FF-11@gated-at.bofh.it>
In reply to#1301594
On Tue, 2016-01-05 at 10:12 -0500, Alan Stern wrote:
> On Mon, 4 Jan 2016, Geyslan G. Bem wrote:
> 
> > >> @@ -404,12 +422,8 @@ static inline char token_mark(struct ehci_hcd *ehci, __hc32 token)
> > >>       return '/';
> > >>  }
> > >>
> > >> -static void qh_lines(
> > >> -     struct ehci_hcd *ehci,
> > >> -     struct ehci_qh *qh,
> > >> -     char **nextp,
> > >> -     unsigned *sizep
> > >> -)
> > >> +static void qh_lines(struct ehci_hcd *ehci, struct ehci_qh *qh,
> > >> +                     char **nextp, unsigned *sizep)
> > >>  {
> > >>       u32                     scratch;
> > >>       u32                     hw_curr;
> > >>
> > >
> > And about that style? Should be done?
> 
> You mean squeezing the function parameters into two lines?  That's 
> okay.
> 
> However, the style in this file is to indent continuation lines by two
> extra tab stops, not to line things up with an open paren on the first
> line.

It's not consistent.
It's a bit of a mix of 1 and 2 tabs, and some others.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1301613

From"Geyslan G. Bem" <geyslan@gmail.com>
Date2016-01-05 16:30 +0100
Message-ID<qNBID-4FF-53@gated-at.bofh.it>
In reply to#1301599
2016-01-05 12:23 GMT-03:00 Joe Perches <joe@perches.com>:
> On Tue, 2016-01-05 at 10:12 -0500, Alan Stern wrote:
>> On Mon, 4 Jan 2016, Geyslan G. Bem wrote:
>>
>> > >> @@ -404,12 +422,8 @@ static inline char token_mark(struct ehci_hcd *ehci, __hc32 token)
>> > >>       return '/';
>> > >>  }
>> > >>
>> > >> -static void qh_lines(
>> > >> -     struct ehci_hcd *ehci,
>> > >> -     struct ehci_qh *qh,
>> > >> -     char **nextp,
>> > >> -     unsigned *sizep
>> > >> -)
>> > >> +static void qh_lines(struct ehci_hcd *ehci, struct ehci_qh *qh,
>> > >> +                     char **nextp, unsigned *sizep)
>> > >>  {
>> > >>       u32                     scratch;
>> > >>       u32                     hw_curr;
>> > >>
>> > >
>> > And about that style? Should be done?
>>
>> You mean squeezing the function parameters into two lines?  That's
>> okay.
Yes. I'll change this patch to do only that squeezing.

>>
>> However, the style in this file is to indent continuation lines by two
>> extra tab stops, not to line things up with an open paren on the first
>> line.
I see. I used 3 tabs, reducing to 2.

>
> It's not consistent.
> It's a bit of a mix of 1 and 2 tabs, and some others.
I noticed it. Maybe to avoid the 80th column there are 1 tab indentations.

>
>



-- 
Regards,

Geyslan G. Bem
hackingbits.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1301615

From"Geyslan G. Bem" <geyslan@gmail.com>
Date2016-01-05 16:40 +0100
Message-ID<qNBSi-4Kz-11@gated-at.bofh.it>
In reply to#1301613
2016-01-05 12:27 GMT-03:00 Geyslan G. Bem <geyslan@gmail.com>:
> 2016-01-05 12:23 GMT-03:00 Joe Perches <joe@perches.com>:
>> On Tue, 2016-01-05 at 10:12 -0500, Alan Stern wrote:
>>> On Mon, 4 Jan 2016, Geyslan G. Bem wrote:
>>>
>>> > >> @@ -404,12 +422,8 @@ static inline char token_mark(struct ehci_hcd *ehci, __hc32 token)
>>> > >>       return '/';
>>> > >>  }
>>> > >>
>>> > >> -static void qh_lines(
>>> > >> -     struct ehci_hcd *ehci,
>>> > >> -     struct ehci_qh *qh,
>>> > >> -     char **nextp,
>>> > >> -     unsigned *sizep
>>> > >> -)
>>> > >> +static void qh_lines(struct ehci_hcd *ehci, struct ehci_qh *qh,
>>> > >> +                     char **nextp, unsigned *sizep)
>>> > >>  {
>>> > >>       u32                     scratch;
>>> > >>       u32                     hw_curr;
>>> > >>
>>> > >
>>> > And about that style? Should be done?
>>>
>>> You mean squeezing the function parameters into two lines?  That's
>>> okay.
> Yes. I'll change this patch to do only that squeezing.
>
>>>
>>> However, the style in this file is to indent continuation lines by two
>>> extra tab stops, not to line things up with an open paren on the first
>>> line.
> I see. I used 3 tabs, reducing to 2.
>
>>
>> It's not consistent.
>> It's a bit of a mix of 1 and 2 tabs, and some others.
> I noticed it. Maybe to avoid the 80th column there are 1 tab indentations.

Others:

946
static struct debug_buffer *alloc_buffer(struct usb_bus *bus,
                ssize_t (*fill_func)(struct debug_buffer *))

has 4 tabs on the second line.

986
static ssize_t debug_output(struct file *file, char __user *user_buf,
                size_t len, loff_t *offset)

has 3 tabs and 4 spaces on the second line (aligned to open paren).

I think we should reduce them too to make the file consistent.

>
>>
>>
>
>
>
> --
> Regards,
>
> Geyslan G. Bem
> hackingbits.com



-- 
Regards,

Geyslan G. Bem
hackingbits.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1301651

FromAlan Stern <stern@rowland.harvard.edu>
Date2016-01-05 17:10 +0100
Message-ID<qNClk-5bm-5@gated-at.bofh.it>
In reply to#1301599
On Tue, 5 Jan 2016, Joe Perches wrote:

> On Tue, 2016-01-05 at 10:12 -0500, Alan Stern wrote:
> > On Mon, 4 Jan 2016, Geyslan G. Bem wrote:
> > 
> > > >> @@ -404,12 +422,8 @@ static inline char token_mark(struct ehci_hcd *ehci, __hc32 token)
> > > >>������ return '/';
> > > >>� }
> > > >>
> > > >> -static void qh_lines(
> > > >> -���� struct ehci_hcd *ehci,
> > > >> -���� struct ehci_qh *qh,
> > > >> -���� char **nextp,
> > > >> -���� unsigned *sizep
> > > >> -)
> > > >> +static void qh_lines(struct ehci_hcd *ehci, struct ehci_qh *qh,
> > > >> +�������������������� char **nextp, unsigned *sizep)
> > > >>� {
> > > >>������ u32�������������������� scratch;
> > > >>������ u32�������������������� hw_curr;
> > > >>
> > > >
> > > And about that style? Should be done?
> > 
> > You mean squeezing the function parameters into two lines?� That's�
> > okay.
> > 
> > However, the style in this file is to indent continuation lines by two
> > extra tab stops, not to line things up with an open paren on the first
> > line.
> 
> It's not consistent.
> It's a bit of a mix of 1 and 2 tabs, and some others.

I know.  That's because the files were written by various people at 
various times and nobody tried to enforce a rigid consistent style.

I'm not even consistent all the time in the things that I write.  There 
are places (see drivers/usb/core/config.c) where I indented 
continuation lines by 4 spaces instead of 2 tab stops.  And there are 
places where a continuation of a continuation gets indented even 
farther.

Trying to come up with hard-and-fast rules for this sort of thing is 
pretty hopeless.  Even "Maximize readability" doesn't work too well, 
because different people find different things most readable.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1301670

FromJoe Perches <joe@perches.com>
Date2016-01-05 17:20 +0100
Message-ID<qNCv1-5eI-35@gated-at.bofh.it>
In reply to#1301651
On Tue, 2016-01-05 at 11:06 -0500, Alan Stern wrote:
> Trying to come up with hard-and-fast rules for this sort of thing is 
> pretty hopeless.  Even "Maximize readability" doesn't work too well, 
> because different people find different things most readable.

Readability is mostly habituation.

Align to open parenthesis is relatively easy to implement,
but it can get out of hand too with long naming.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1301679

FromAlan Stern <stern@rowland.harvard.edu>
Date2016-01-05 17:30 +0100
Message-ID<qNCEH-5ih-31@gated-at.bofh.it>
In reply to#1301670
On Tue, 5 Jan 2016, Joe Perches wrote:

> On Tue, 2016-01-05 at 11:06 -0500, Alan Stern wrote:
> > Trying to come up with hard-and-fast rules for this sort of thing is�
> > pretty hopeless.� Even "Maximize readability" doesn't work too well,�
> > because different people find different things most readable.
> 
> Readability is mostly habituation.

Indeed.

> Align to open parenthesis is relatively easy to implement,
> but it can get out of hand too with long naming.

That's why I dislike it.  Plus the fact that it results in
continuations of different lines being indented by different amounts.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1301717

From"Geyslan G. Bem" <geyslan@gmail.com>
Date2016-01-05 18:10 +0100
Message-ID<qNDho-5Oc-17@gated-at.bofh.it>
In reply to#1301679
2016-01-05 13:29 GMT-03:00 Alan Stern <stern@rowland.harvard.edu>:
> On Tue, 5 Jan 2016, Joe Perches wrote:
>
>> On Tue, 2016-01-05 at 11:06 -0500, Alan Stern wrote:
>> > Trying to come up with hard-and-fast rules for this sort of thing is
>> > pretty hopeless.  Even "Maximize readability" doesn't work too well,
>> > because different people find different things most readable.
>>
>> Readability is mostly habituation.
>
> Indeed.

Ditto.

>
>> Align to open parenthesis is relatively easy to implement,
>> but it can get out of hand too with long naming.

It's easy and it's consistent (the place of sequential lines).

>
> That's why I dislike it.  Plus the fact that it results in
> continuations of different lines being indented by different amounts.

The different amounts is the price to pay for that indentation, but it
will mostly make the style consistent and easy as Joe stated. I'm not
claiming for that changing, just debating. :-D
But IMHO standardization could make things easier.

>
> Alan Stern
>



-- 
Regards,

Geyslan G. Bem
hackingbits.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1301602

FromJoe Perches <joe@perches.com>
Date2016-01-05 16:30 +0100
Message-ID<qNBIC-4FF-19@gated-at.bofh.it>
In reply to#1301594
On Tue, 2016-01-05 at 10:12 -0500, Alan Stern wrote:
> On Mon, 4 Jan 2016, Geyslan G. Bem wrote:
> 
> > >> @@ -404,12 +422,8 @@ static inline char token_mark(struct
> ehci_hcd *ehci, __hc32 token)
> > >>       return '/';
> > >>  }
> > >>
> > >> -static void qh_lines(
> > >> -     struct ehci_hcd *ehci,
> > >> -     struct ehci_qh *qh,
> > >> -     char **nextp,
> > >> -     unsigned *sizep
> > >> -)
> > >> +static void qh_lines(struct ehci_hcd *ehci, struct ehci_qh *qh,
> > >> +                     char **nextp, unsigned *sizep)
> > >>  {
> > >>       u32                     scratch;
> > >>       u32                     hw_curr;
> > >>
> > >
> > And about that style? Should be done?
> 
> You mean squeezing the function parameters into two lines?  That's 
> okay.
> 
> However, the style in this file is to indent continuation lines by
> two
> extra tab stops, not to line things up with an open paren on the
> first
> line.
> 
> Alan Stern
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web