[PATCH] staging: Fix spacing between function name and parentheses
Fixes checkpatch coding style warning about unneeded space between function name an parentheses. Signed-off-by: Nicholas Krause <xerofoify@gmail.com> --- Untested drivers/staging/octeon-usb/octeon-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/octeon-usb/octeon-hcd.c b/drivers/staging/octeon-usb/octeon-hcd.c index 5f9db4c..bbeb0cc 100644 --- a/drivers/staging/octeon-usb/octeon-hcd.c +++ b/drivers/staging/octeon-usb/octeon-hcd.c @@ -412,7 +412,7 @@ struct octeon_hcd { type c; \ while (1) { \ c.u32 = __cvmx_usb_read_csr32(usb, address); \ - if (c.s.field op (value)) { \ + if (c.s.field op(value)) { \ result = 0; \ break; \ } else if (cvmx_get_cycle() > done) { \ -- 1.9.1
On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
Fixes checkpatch coding style warning about unneeded space between function name an parentheses.
Signed-off-by: Nicholas Krause <xerofoify@gmail.com> --- Untested drivers/staging/octeon-usb/octeon-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/octeon-usb/octeon-hcd.c b/drivers/staging/octeon-usb/octeon-hcd.c index 5f9db4c..bbeb0cc 100644 --- a/drivers/staging/octeon-usb/octeon-hcd.c +++ b/drivers/staging/octeon-usb/octeon-hcd.c @@ -412,7 +412,7 @@ struct octeon_hcd { type c; \ while (1) { \ c.u32 = __cvmx_usb_read_csr32(usb, address); \ - if (c.s.field op (value)) { \ + if (c.s.field op(value)) { \
have you read the code before modifying it? this is not a function. have you seen how CVMX_WAIT_FOR_FIELD32 is being called? on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "==" so when called the macro will be c.s.field == (value). if your patch is applied then it will become c.s.field ==(value) .. will that be correct ? thanks sudip
result = 0; \ break; \ } else if (cvmx_get_cycle() > done) { \ -- 1.9.1
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
It also works as value is surrounded by (), though I do not think the patch itself is right or useful. Dave Tian dave.jing.tian@gmail.com On Oct 11, 2014, at 12:58 PM, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
Fixes checkpatch coding style warning about unneeded space between function name an parentheses.
Signed-off-by: Nicholas Krause <xerofoify@gmail.com> --- Untested drivers/staging/octeon-usb/octeon-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/octeon-usb/octeon-hcd.c b/drivers/staging/octeon-usb/octeon-hcd.c index 5f9db4c..bbeb0cc 100644 --- a/drivers/staging/octeon-usb/octeon-hcd.c +++ b/drivers/staging/octeon-usb/octeon-hcd.c @@ -412,7 +412,7 @@ struct octeon_hcd { type c; \ while (1) { \ c.u32 = __cvmx_usb_read_csr32(usb, address); \ - if (c.s.field op (value)) { \ + if (c.s.field op(value)) { \
have you read the code before modifying it? this is not a function. have you seen how CVMX_WAIT_FOR_FIELD32 is being called? on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "==" so when called the macro will be c.s.field == (value). if your patch is applied then it will become c.s.field ==(value) .. will that be correct ?
thanks sudip
result = 0; \ break; \ } else if (cvmx_get_cycle() > done) { \ -- 1.9.1
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Hi Dave, It will work. But my point of saying that was c.s.field ==(value) is again not according to the style. thanks sudip On Sat, Oct 11, 2014 at 10:53 AM, Dave Tian <dave.jing.tian@gmail.com> wrote:
It also works as value is surrounded by (), though I do not think the patch itself is right or useful.
Dave Tian dave.jing.tian@gmail.com
On Oct 11, 2014, at 12:58 PM, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
Fixes checkpatch coding style warning about unneeded space between function name an parentheses.
Signed-off-by: Nicholas Krause <xerofoify@gmail.com> --- Untested drivers/staging/octeon-usb/octeon-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/octeon-usb/octeon-hcd.c b/drivers/staging/octeon-usb/octeon-hcd.c index 5f9db4c..bbeb0cc 100644 --- a/drivers/staging/octeon-usb/octeon-hcd.c +++ b/drivers/staging/octeon-usb/octeon-hcd.c @@ -412,7 +412,7 @@ struct octeon_hcd { type c; \ while (1) { \ c.u32 = __cvmx_usb_read_csr32(usb, address); \ - if (c.s.field op (value)) { \ + if (c.s.field op(value)) { \
have you read the code before modifying it? this is not a function. have you seen how CVMX_WAIT_FOR_FIELD32 is being called? on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "==" so when called the macro will be c.s.field == (value). if your patch is applied then it will become c.s.field ==(value) .. will that be correct ?
thanks sudip
result = 0; \ break; \ } else if (cvmx_get_cycle() > done) { \ -- 1.9.1
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Agreed - that is why I mentioned the patch is neither right nor useful:) -daveti On Oct 11, 2014, at 2:08 PM, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
Hi Dave, It will work. But my point of saying that was c.s.field ==(value) is again not according to the style.
thanks sudip
On Sat, Oct 11, 2014 at 10:53 AM, Dave Tian <dave.jing.tian@gmail.com> wrote:
It also works as value is surrounded by (), though I do not think the patch itself is right or useful.
Dave Tian dave.jing.tian@gmail.com
On Oct 11, 2014, at 12:58 PM, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
Fixes checkpatch coding style warning about unneeded space between function name an parentheses.
Signed-off-by: Nicholas Krause <xerofoify@gmail.com> --- Untested drivers/staging/octeon-usb/octeon-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/octeon-usb/octeon-hcd.c b/drivers/staging/octeon-usb/octeon-hcd.c index 5f9db4c..bbeb0cc 100644 --- a/drivers/staging/octeon-usb/octeon-hcd.c +++ b/drivers/staging/octeon-usb/octeon-hcd.c @@ -412,7 +412,7 @@ struct octeon_hcd { type c; \ while (1) { \ c.u32 = __cvmx_usb_read_csr32(usb, address); \ - if (c.s.field op (value)) { \ + if (c.s.field op(value)) { \
have you read the code before modifying it? this is not a function. have you seen how CVMX_WAIT_FOR_FIELD32 is being called? on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "==" so when called the macro will be c.s.field == (value). if your patch is applied then it will become c.s.field ==(value) .. will that be correct ?
thanks sudip
result = 0; \ break; \ } else if (cvmx_get_cycle() > done) { \ -- 1.9.1
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
I think that, in this case, checkpatch.pl contributed: $ ./scripts/checkpatch.pl -f drivers/staging/octeon-usb/octeon-hcd.c WARNING: space prohibited between function name and open parenthesis '(' #415: FILE: drivers/staging/octeon-usb/octeon-hcd.c:415: + if (c.s.field op (value)) { \ On Sat, Oct 11, 2014 at 8:11 AM, Dave Tian <dave.jing.tian@gmail.com> wrote:
Agreed - that is why I mentioned the patch is neither right nor useful:)
-daveti
On Oct 11, 2014, at 2:08 PM, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
Hi Dave, It will work. But my point of saying that was c.s.field ==(value) is again not according to the style.
thanks sudip
On Sat, Oct 11, 2014 at 10:53 AM, Dave Tian <dave.jing.tian@gmail.com> wrote:
It also works as value is surrounded by (), though I do not think the patch itself is right or useful.
Dave Tian dave.jing.tian@gmail.com
On Oct 11, 2014, at 12:58 PM, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
Fixes checkpatch coding style warning about unneeded space between function name an parentheses.
Signed-off-by: Nicholas Krause <xerofoify@gmail.com> --- Untested drivers/staging/octeon-usb/octeon-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/octeon-usb/octeon-hcd.c b/drivers/staging/octeon-usb/octeon-hcd.c index 5f9db4c..bbeb0cc 100644 --- a/drivers/staging/octeon-usb/octeon-hcd.c +++ b/drivers/staging/octeon-usb/octeon-hcd.c @@ -412,7 +412,7 @@ struct octeon_hcd { type c; \ while (1) { \ c.u32 = __cvmx_usb_read_csr32(usb, address); \ - if (c.s.field op (value)) { \ + if (c.s.field op(value)) { \
have you read the code before modifying it? this is not a function. have you seen how CVMX_WAIT_FOR_FIELD32 is being called? on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "==" so when called the macro will be c.s.field == (value). if your patch is applied then it will become c.s.field ==(value) .. will that be correct ?
thanks sudip
result = 0; \ break; \ } else if (cvmx_get_cycle() > done) { \ -- 1.9.1
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Peter
I agree. But in my opinion checkpatch is here to help us fix style problems , but we should not blindly act on checkpatch warnings. thanks sudip On Sat, Oct 11, 2014 at 1:57 PM, Peter Senna Tschudin <peter.senna@gmail.com> wrote:
I think that, in this case, checkpatch.pl contributed:
$ ./scripts/checkpatch.pl -f drivers/staging/octeon-usb/octeon-hcd.c WARNING: space prohibited between function name and open parenthesis '(' #415: FILE: drivers/staging/octeon-usb/octeon-hcd.c:415: + if (c.s.field op (value)) { \
On Sat, Oct 11, 2014 at 8:11 AM, Dave Tian <dave.jing.tian@gmail.com> wrote:
Agreed - that is why I mentioned the patch is neither right nor useful:)
-daveti
On Oct 11, 2014, at 2:08 PM, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
Hi Dave, It will work. But my point of saying that was c.s.field ==(value) is again not according to the style.
thanks sudip
On Sat, Oct 11, 2014 at 10:53 AM, Dave Tian <dave.jing.tian@gmail.com> wrote:
It also works as value is surrounded by (), though I do not think the patch itself is right or useful.
Dave Tian dave.jing.tian@gmail.com
On Oct 11, 2014, at 12:58 PM, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
Fixes checkpatch coding style warning about unneeded space between function name an parentheses.
Signed-off-by: Nicholas Krause <xerofoify@gmail.com> --- Untested drivers/staging/octeon-usb/octeon-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/octeon-usb/octeon-hcd.c b/drivers/staging/octeon-usb/octeon-hcd.c index 5f9db4c..bbeb0cc 100644 --- a/drivers/staging/octeon-usb/octeon-hcd.c +++ b/drivers/staging/octeon-usb/octeon-hcd.c @@ -412,7 +412,7 @@ struct octeon_hcd { type c; \ while (1) { \ c.u32 = __cvmx_usb_read_csr32(usb, address); \ - if (c.s.field op (value)) { \ + if (c.s.field op(value)) { \
have you read the code before modifying it? this is not a function. have you seen how CVMX_WAIT_FOR_FIELD32 is being called? on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "==" so when called the macro will be c.s.field == (value). if your patch is applied then it will become c.s.field ==(value) .. will that be correct ?
thanks sudip
result = 0; \ break; \ } else if (cvmx_get_cycle() > done) { \ -- 1.9.1
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Peter
Even if you use checkpath you _should_ understand what you are changing. The output of checkpatch merely there to help. In this case you can see that this is a macro just a few lines up in the code. On 11 Oct 2014 11:46, "Sudip Mukherjee" <sudipm.mukherjee@gmail.com> wrote:
I agree. But in my opinion checkpatch is here to help us fix style problems , but we should not blindly act on checkpatch warnings.
thanks sudip
On Sat, Oct 11, 2014 at 1:57 PM, Peter Senna Tschudin <peter.senna@gmail.com> wrote:
I think that, in this case, checkpatch.pl contributed:
$ ./scripts/checkpatch.pl -f drivers/staging/octeon-usb/octeon-hcd.c WARNING: space prohibited between function name and open parenthesis '(' #415: FILE: drivers/staging/octeon-usb/octeon-hcd.c:415: + if (c.s.field op (value)) { \
On Sat, Oct 11, 2014 at 8:11 AM, Dave Tian <dave.jing.tian@gmail.com> wrote:
Agreed - that is why I mentioned the patch is neither right nor useful:)
-daveti
On Oct 11, 2014, at 2:08 PM, Sudip Mukherjee < sudipm.mukherjee@gmail.com> wrote:
Hi Dave, It will work. But my point of saying that was c.s.field ==(value) is again not according to the style.
thanks sudip
On Sat, Oct 11, 2014 at 10:53 AM, Dave Tian <dave.jing.tian@gmail.com> wrote:
It also works as value is surrounded by (), though I do not think the patch itself is right or useful.
Dave Tian dave.jing.tian@gmail.com
On Oct 11, 2014, at 12:58 PM, Sudip Mukherjee < sudipm.mukherjee@gmail.com> wrote:
On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
Fixes checkpatch coding style warning about unneeded space between function name an parentheses.
Signed-off-by: Nicholas Krause <xerofoify@gmail.com> --- Untested drivers/staging/octeon-usb/octeon-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/octeon-usb/octeon-hcd.c b/drivers/staging/octeon-usb/octeon-hcd.c index 5f9db4c..bbeb0cc 100644 --- a/drivers/staging/octeon-usb/octeon-hcd.c +++ b/drivers/staging/octeon-usb/octeon-hcd.c @@ -412,7 +412,7 @@ struct octeon_hcd { type c; \ while (1) { \ c.u32 = __cvmx_usb_read_csr32(usb, address); \ - if (c.s.field op (value)) { \ + if (c.s.field op(value)) { \
have you read the code before modifying it? this is not a function. have you seen how CVMX_WAIT_FOR_FIELD32 is being called? on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "==" so when called the macro will be c.s.field == (value). if your patch is applied then it will become c.s.field ==(value) .. will that be correct ?
thanks sudip
result = 0;
\
break;
\
} else if (cvmx_get_cycle() > done) {
\
-- 1.9.1
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Peter
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Thank you for your help, I'll study the code and see what I can do about it. Do you have any suggestions of how to fix this checkpatch warning? Nick On 14-10-11 05:53 AM, Kristofer Hallin wrote:
Even if you use checkpath you _should_ understand what you are changing. The output of checkpatch merely there to help.
In this case you can see that this is a macro just a few lines up in the code. On 11 Oct 2014 11:46, "Sudip Mukherjee" <sudipm.mukherjee@gmail.com> wrote:
I agree. But in my opinion checkpatch is here to help us fix style problems , but we should not blindly act on checkpatch warnings.
thanks sudip
On Sat, Oct 11, 2014 at 1:57 PM, Peter Senna Tschudin <peter.senna@gmail.com> wrote:
I think that, in this case, checkpatch.pl contributed:
$ ./scripts/checkpatch.pl -f drivers/staging/octeon-usb/octeon-hcd.c WARNING: space prohibited between function name and open parenthesis '(' #415: FILE: drivers/staging/octeon-usb/octeon-hcd.c:415: + if (c.s.field op (value)) { \
On Sat, Oct 11, 2014 at 8:11 AM, Dave Tian <dave.jing.tian@gmail.com> wrote:
Agreed - that is why I mentioned the patch is neither right nor useful:)
-daveti
On Oct 11, 2014, at 2:08 PM, Sudip Mukherjee < sudipm.mukherjee@gmail.com> wrote:
Hi Dave, It will work. But my point of saying that was c.s.field ==(value) is again not according to the style.
thanks sudip
On Sat, Oct 11, 2014 at 10:53 AM, Dave Tian <dave.jing.tian@gmail.com> wrote:
It also works as value is surrounded by (), though I do not think the patch itself is right or useful.
Dave Tian dave.jing.tian@gmail.com
On Oct 11, 2014, at 12:58 PM, Sudip Mukherjee < sudipm.mukherjee@gmail.com> wrote:
On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
Fixes checkpatch coding style warning about unneeded space between function name an parentheses.
Signed-off-by: Nicholas Krause <xerofoify@gmail.com> --- Untested drivers/staging/octeon-usb/octeon-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/octeon-usb/octeon-hcd.c b/drivers/staging/octeon-usb/octeon-hcd.c index 5f9db4c..bbeb0cc 100644 --- a/drivers/staging/octeon-usb/octeon-hcd.c +++ b/drivers/staging/octeon-usb/octeon-hcd.c @@ -412,7 +412,7 @@ struct octeon_hcd { type c; \ while (1) { \ c.u32 = __cvmx_usb_read_csr32(usb, address); \ - if (c.s.field op (value)) { \ + if (c.s.field op(value)) { \
have you read the code before modifying it? this is not a function. have you seen how CVMX_WAIT_FOR_FIELD32 is being called? on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "==" so when called the macro will be c.s.field == (value). if your patch is applied then it will become c.s.field ==(value) .. will that be correct ?
thanks sudip
result = 0;
\
break;
\
} else if (cvmx_get_cycle() > done) {
\
-- 1.9.1
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Peter
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Sat, Oct 11, 2014 at 09:44:05AM -0400, nick wrote:
Thank you for your help, I'll study the code and see what I can do about it. Do you have any suggestions of how to fix this checkpatch warning?
Ignore it. The checker has clearly triggered on a false positive -- this is not a function call, and should not be held to that standard. (Take a look at where the macro is actually used, to see what's going on here). Move on to find something more interesting to fix. Hugo.
Nick
On 14-10-11 05:53 AM, Kristofer Hallin wrote:
Even if you use checkpath you _should_ understand what you are changing. The output of checkpatch merely there to help.
In this case you can see that this is a macro just a few lines up in the code. On 11 Oct 2014 11:46, "Sudip Mukherjee" <sudipm.mukherjee@gmail.com> wrote:
I agree. But in my opinion checkpatch is here to help us fix style problems , but we should not blindly act on checkpatch warnings.
thanks sudip
On Sat, Oct 11, 2014 at 1:57 PM, Peter Senna Tschudin <peter.senna@gmail.com> wrote:
I think that, in this case, checkpatch.pl contributed:
$ ./scripts/checkpatch.pl -f drivers/staging/octeon-usb/octeon-hcd.c WARNING: space prohibited between function name and open parenthesis '(' #415: FILE: drivers/staging/octeon-usb/octeon-hcd.c:415: + if (c.s.field op (value)) { \
On Sat, Oct 11, 2014 at 8:11 AM, Dave Tian <dave.jing.tian@gmail.com> wrote:
Agreed - that is why I mentioned the patch is neither right nor useful:)
-daveti
On Oct 11, 2014, at 2:08 PM, Sudip Mukherjee < sudipm.mukherjee@gmail.com> wrote:
Hi Dave, It will work. But my point of saying that was c.s.field ==(value) is again not according to the style.
thanks sudip
On Sat, Oct 11, 2014 at 10:53 AM, Dave Tian <dave.jing.tian@gmail.com> wrote:
It also works as value is surrounded by (), though I do not think the patch itself is right or useful.
Dave Tian dave.jing.tian@gmail.com
On Oct 11, 2014, at 12:58 PM, Sudip Mukherjee < sudipm.mukherjee@gmail.com> wrote:
On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
Fixes checkpatch coding style warning about unneeded space between function name an parentheses.
Signed-off-by: Nicholas Krause <xerofoify@gmail.com> --- Untested drivers/staging/octeon-usb/octeon-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/octeon-usb/octeon-hcd.c b/drivers/staging/octeon-usb/octeon-hcd.c index 5f9db4c..bbeb0cc 100644 --- a/drivers/staging/octeon-usb/octeon-hcd.c +++ b/drivers/staging/octeon-usb/octeon-hcd.c @@ -412,7 +412,7 @@ struct octeon_hcd { type c; \ while (1) { \ c.u32 = __cvmx_usb_read_csr32(usb, address); \ - if (c.s.field op (value)) { \ + if (c.s.field op(value)) { \
have you read the code before modifying it? this is not a function. have you seen how CVMX_WAIT_FOR_FIELD32 is being called? on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "==" so when called the macro will be c.s.field == (value). if your patch is applied then it will become c.s.field ==(value) .. will that be correct ?
thanks sudip
result = 0;
\
break;
\
} else if (cvmx_get_cycle() > done) {
\
-- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Happiness is mandatory. Are you happy? ---
Thanks Hugo, Sorry about that. On the other hand was the patch good in terms of format? Cheers Nick On 14-10-11 09:52 AM, Hugo Mills wrote:
On Sat, Oct 11, 2014 at 09:44:05AM -0400, nick wrote:
Thank you for your help, I'll study the code and see what I can do about it. Do you have any suggestions of how to fix this checkpatch warning?
Ignore it. The checker has clearly triggered on a false positive -- this is not a function call, and should not be held to that standard. (Take a look at where the macro is actually used, to see what's going on here). Move on to find something more interesting to fix.
Hugo.
Nick
On 14-10-11 05:53 AM, Kristofer Hallin wrote:
Even if you use checkpath you _should_ understand what you are changing. The output of checkpatch merely there to help.
In this case you can see that this is a macro just a few lines up in the code. On 11 Oct 2014 11:46, "Sudip Mukherjee" <sudipm.mukherjee@gmail.com> wrote:
I agree. But in my opinion checkpatch is here to help us fix style problems , but we should not blindly act on checkpatch warnings.
thanks sudip
On Sat, Oct 11, 2014 at 1:57 PM, Peter Senna Tschudin <peter.senna@gmail.com> wrote:
I think that, in this case, checkpatch.pl contributed:
$ ./scripts/checkpatch.pl -f drivers/staging/octeon-usb/octeon-hcd.c WARNING: space prohibited between function name and open parenthesis '(' #415: FILE: drivers/staging/octeon-usb/octeon-hcd.c:415: + if (c.s.field op (value)) { \
On Sat, Oct 11, 2014 at 8:11 AM, Dave Tian <dave.jing.tian@gmail.com> wrote:
Agreed - that is why I mentioned the patch is neither right nor useful:)
-daveti
On Oct 11, 2014, at 2:08 PM, Sudip Mukherjee < sudipm.mukherjee@gmail.com> wrote:
Hi Dave, It will work. But my point of saying that was c.s.field ==(value) is again not according to the style.
thanks sudip
On Sat, Oct 11, 2014 at 10:53 AM, Dave Tian <dave.jing.tian@gmail.com> wrote:
It also works as value is surrounded by (), though I do not think the patch itself is right or useful.
Dave Tian dave.jing.tian@gmail.com
On Oct 11, 2014, at 12:58 PM, Sudip Mukherjee < sudipm.mukherjee@gmail.com> wrote:
On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
Fixes checkpatch coding style warning about unneeded space between function name an parentheses.
Signed-off-by: Nicholas Krause <xerofoify@gmail.com> --- Untested drivers/staging/octeon-usb/octeon-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/octeon-usb/octeon-hcd.c b/drivers/staging/octeon-usb/octeon-hcd.c index 5f9db4c..bbeb0cc 100644 --- a/drivers/staging/octeon-usb/octeon-hcd.c +++ b/drivers/staging/octeon-usb/octeon-hcd.c @@ -412,7 +412,7 @@ struct octeon_hcd { type c; \ while (1) { \ c.u32 = __cvmx_usb_read_csr32(usb, address); \ - if (c.s.field op (value)) { \ + if (c.s.field op(value)) { \
have you read the code before modifying it? this is not a function. have you seen how CVMX_WAIT_FOR_FIELD32 is being called? on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "==" so when called the macro will be c.s.field == (value). if your patch is applied then it will become c.s.field ==(value) .. will that be correct ?
thanks sudip
result = 0;
\
break;
\
} else if (cvmx_get_cycle() > done) {
\
Hey Nick, Nice try to fix a checkpatch warning. But do read what you're changing. Yes your format is right. If you haven't already, take a look at "git send-email" . Have fun hacking :D Regards, Karthik Nayak On Sat, Oct 11, 2014 at 7:47 PM, nick <xerofoify@gmail.com> wrote:
Thanks Hugo, Sorry about that. On the other hand was the patch good in terms of format? Cheers Nick
On 14-10-11 09:52 AM, Hugo Mills wrote:
On Sat, Oct 11, 2014 at 09:44:05AM -0400, nick wrote:
Thank you for your help, I'll study the code and see what I can do about it. Do you have any suggestions of how to fix this checkpatch warning?
Ignore it. The checker has clearly triggered on a false positive -- this is not a function call, and should not be held to that standard. (Take a look at where the macro is actually used, to see what's going on here). Move on to find something more interesting to fix.
Hugo.
Nick
On 14-10-11 05:53 AM, Kristofer Hallin wrote:
Even if you use checkpath you _should_ understand what you are changing. The output of checkpatch merely there to help.
In this case you can see that this is a macro just a few lines up in the code. On 11 Oct 2014 11:46, "Sudip Mukherjee" <sudipm.mukherjee@gmail.com> wrote:
I agree. But in my opinion checkpatch is here to help us fix style problems , but we should not blindly act on checkpatch warnings.
thanks sudip
On Sat, Oct 11, 2014 at 1:57 PM, Peter Senna Tschudin <peter.senna@gmail.com> wrote:
I think that, in this case, checkpatch.pl contributed:
$ ./scripts/checkpatch.pl -f drivers/staging/octeon-usb/octeon-hcd.c WARNING: space prohibited between function name and open parenthesis '(' #415: FILE: drivers/staging/octeon-usb/octeon-hcd.c:415: + if (c.s.field op (value)) { \
On Sat, Oct 11, 2014 at 8:11 AM, Dave Tian <dave.jing.tian@gmail.com> wrote:
Agreed - that is why I mentioned the patch is neither right nor useful:)
-daveti
On Oct 11, 2014, at 2:08 PM, Sudip Mukherjee < sudipm.mukherjee@gmail.com> wrote:
Hi Dave, It will work. But my point of saying that was c.s.field ==(value) is again not according to the style.
thanks sudip
On Sat, Oct 11, 2014 at 10:53 AM, Dave Tian <dave.jing.tian@gmail.com> wrote:
It also works as value is surrounded by (), though I do not think the patch itself is right or useful.
Dave Tian dave.jing.tian@gmail.com
On Oct 11, 2014, at 12:58 PM, Sudip Mukherjee < sudipm.mukherjee@gmail.com> wrote:
On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
Fixes checkpatch coding style warning about unneeded space between function name an parentheses.
Signed-off-by: Nicholas Krause <xerofoify@gmail.com> --- Untested drivers/staging/octeon-usb/octeon-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/octeon-usb/octeon-hcd.c b/drivers/staging/octeon-usb/octeon-hcd.c index 5f9db4c..bbeb0cc 100644 --- a/drivers/staging/octeon-usb/octeon-hcd.c +++ b/drivers/staging/octeon-usb/octeon-hcd.c @@ -412,7 +412,7 @@ struct octeon_hcd { type c; \ while (1) { \ c.u32 = __cvmx_usb_read_csr32(usb, address); \ - if (c.s.field op (value)) { \ + if (c.s.field op(value)) { \
have you read the code before modifying it? this is not a function. have you seen how CVMX_WAIT_FOR_FIELD32 is being called? on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "==" so when called the macro will be c.s.field == (value). if your patch is applied then it will become c.s.field ==(value) .. will that be correct ?
thanks sudip
result = 0;
\
break;
\
} else if (cvmx_get_cycle() > done) {
\
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Great to known. Sorry about not reading the code, will check more carefully before I fix it. Regards Nick On 14-10-11 11:25 AM, karthik nayak wrote:
Hey Nick, Nice try to fix a checkpatch warning. But do read what you're changing. Yes your format is right. If you haven't already, take a look at "git send-email" . Have fun hacking :D Regards, Karthik Nayak
On Sat, Oct 11, 2014 at 7:47 PM, nick <xerofoify@gmail.com> wrote:
Thanks Hugo, Sorry about that. On the other hand was the patch good in terms of format? Cheers Nick
On 14-10-11 09:52 AM, Hugo Mills wrote:
On Sat, Oct 11, 2014 at 09:44:05AM -0400, nick wrote:
Thank you for your help, I'll study the code and see what I can do about it. Do you have any suggestions of how to fix this checkpatch warning?
Ignore it. The checker has clearly triggered on a false positive -- this is not a function call, and should not be held to that standard. (Take a look at where the macro is actually used, to see what's going on here). Move on to find something more interesting to fix.
Hugo.
Nick
On 14-10-11 05:53 AM, Kristofer Hallin wrote:
Even if you use checkpath you _should_ understand what you are changing. The output of checkpatch merely there to help.
In this case you can see that this is a macro just a few lines up in the code. On 11 Oct 2014 11:46, "Sudip Mukherjee" <sudipm.mukherjee@gmail.com> wrote:
I agree. But in my opinion checkpatch is here to help us fix style problems , but we should not blindly act on checkpatch warnings.
thanks sudip
On Sat, Oct 11, 2014 at 1:57 PM, Peter Senna Tschudin <peter.senna@gmail.com> wrote:
I think that, in this case, checkpatch.pl contributed:
$ ./scripts/checkpatch.pl -f drivers/staging/octeon-usb/octeon-hcd.c WARNING: space prohibited between function name and open parenthesis '(' #415: FILE: drivers/staging/octeon-usb/octeon-hcd.c:415: + if (c.s.field op (value)) { \
On Sat, Oct 11, 2014 at 8:11 AM, Dave Tian <dave.jing.tian@gmail.com> wrote:
Agreed - that is why I mentioned the patch is neither right nor useful:)
-daveti
On Oct 11, 2014, at 2:08 PM, Sudip Mukherjee < sudipm.mukherjee@gmail.com> wrote:
Hi Dave, It will work. But my point of saying that was c.s.field ==(value) is again not according to the style.
thanks sudip
On Sat, Oct 11, 2014 at 10:53 AM, Dave Tian <dave.jing.tian@gmail.com> wrote:
It also works as value is surrounded by (), though I do not think the patch itself is right or useful.
Dave Tian dave.jing.tian@gmail.com
On Oct 11, 2014, at 12:58 PM, Sudip Mukherjee < sudipm.mukherjee@gmail.com> wrote:
On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
Fixes checkpatch coding style warning about unneeded space between function name an parentheses.
Signed-off-by: Nicholas Krause <xerofoify@gmail.com> --- Untested drivers/staging/octeon-usb/octeon-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/octeon-usb/octeon-hcd.c b/drivers/staging/octeon-usb/octeon-hcd.c index 5f9db4c..bbeb0cc 100644 --- a/drivers/staging/octeon-usb/octeon-hcd.c +++ b/drivers/staging/octeon-usb/octeon-hcd.c @@ -412,7 +412,7 @@ struct octeon_hcd { type c; \ while (1) { \ c.u32 = __cvmx_usb_read_csr32(usb, address); \ - if (c.s.field op (value)) { \ + if (c.s.field op(value)) { \
have you read the code before modifying it? this is not a function. have you seen how CVMX_WAIT_FOR_FIELD32 is being called? on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "==" so when called the macro will be c.s.field == (value). if your patch is applied then it will become c.s.field ==(value) .. will that be correct ?
thanks sudip
result = 0;
\
break;
\
} else if (cvmx_get_cycle() > done) {
\
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Sat, 11 Oct 2014 14:52:40 +0100, Hugo Mills said:
On Sat, Oct 11, 2014 at 09:44:05AM -0400, nick wrote:
Thank you for your help, I'll study the code and see what I can do about it. Do you have any suggestions of how to fix this checkpatch warning?
Ignore it. The checker has clearly triggered on a false positive -- this is not a function call, and should not be held to that standard. (Take a look at where the macro is actually used, to see what's going on here). Move on to find something more interesting to fix.
Am I the only one suspicious of the fact that Nick found one of the few false positives rather than one of the plentiful actual style problems?
Valdis, I do understand your concern with me finding one of the few false positives, due to my issues already with the community. I am trying my best now to improve and work toward good,solid work that is of actual use to the community and avoid shitty patches and not listening like I did for the last few months. Sorry, Nick On 14-10-12 06:34 PM, Valdis.Kletnieks@vt.edu wrote:
On Sat, 11 Oct 2014 14:52:40 +0100, Hugo Mills said:
On Sat, Oct 11, 2014 at 09:44:05AM -0400, nick wrote:
Thank you for your help, I'll study the code and see what I can do about it. Do you have any suggestions of how to fix this checkpatch warning?
Ignore it. The checker has clearly triggered on a false positive -- this is not a function call, and should not be held to that standard. (Take a look at where the macro is actually used, to see what's going on here). Move on to find something more interesting to fix.
Am I the only one suspicious of the fact that Nick found one of the few false positives rather than one of the plentiful actual style problems?
On Sun, 12 Oct 2014 22:31:12 -0400, nick said:
Valdis, I do understand your concern with me finding one of the few false positives, due to my issues already with the community. I am trying my best now to improve and work toward good,solid work that is of actual use to the community and avoid shitty patches and not listening like I did for the last few months.
Forget it Nick. We've heard that too many times. And this time, you blew it by making your bad patch a bit *too* unbelievable. We're tired of your trolling. Where's my drum of Troll-be-gone?
On Mon, Oct 13, 2014 at 4:04 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Sat, 11 Oct 2014 14:52:40 +0100, Hugo Mills said:
On Sat, Oct 11, 2014 at 09:44:05AM -0400, nick wrote:
Thank you for your help, I'll study the code and see what I can do about it. Do you have any suggestions of how to fix this checkpatch warning?
Ignore it. The checker has clearly triggered on a false positive -- this is not a function call, and should not be held to that standard. (Take a look at where the macro is actually used, to see what's going on here). Move on to find something more interesting to fix.
Am I the only one suspicious of the fact that Nick found one of the few false positives rather than one of the plentiful actual style problems? no , you are not the only one. That particular file has lots of checkpatch warning , and our Nick choose just the one which is a false positive.
-----Original Message----- From: kernelnewbies-bounces@kernelnewbies.org [mailto:kernelnewbies-bounces@kernelnewbies.org] On Behalf Of Sudip Mukherjee Sent: Sunday, October 12, 2014 10:56 PM To: Valdis Kletnieks Cc: Dave Tian; nick; Kristofer Hallin; kernelnewbies; Peter Senna Tschudin; Hugo Mills Subject: Re: [PATCH] staging: Fix spacing between function name and parentheses On Mon, Oct 13, 2014 at 4:04 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Sat, 11 Oct 2014 14:52:40 +0100, Hugo Mills said:
On Sat, Oct 11, 2014 at 09:44:05AM -0400, nick wrote:
Thank you for your help, I'll study the code and see what I can do about it. Do you have any suggestions of how to fix this checkpatch warning?
Ignore it. The checker has clearly triggered on a false positive -- this is not a function call, and should not be held to that standard. (Take a look at where the macro is actually used, to see what's going on here). Move on to find something more interesting to fix.
Am I the only one suspicious of the fact that Nick found one of the few false positives rather than one of the plentiful actual style problems? no , you are not the only one. That particular file has lots of checkpatch warning , and our Nick choose just the one which is a false positive.
What is wrong with you people - were you never on nntp and learned how to ignore trolls? I only read this list and Nicholas Krause is a pain - why where there ~11 responses to his stuff - he should be ignored - he is not banned to never respond to the idiot. Nobody wants him, he only wants a byline of minor fame by says 'he I wrote some of linux' 3 months of this crap and you are still all entertaining someone with no code skill accept from adding/removing spaces - we all need house cleaners - but I would not trust him to clean my toilet correctly. I raise the simple motion that when Nicholas Krause posts - NOBODY responds to him - EVER - under threat of torture or whatever - for whatever reason - my joy of lurking here has been ruined by a single IDIOT - if this was nntp he would have wandered off a long time ago with ignores - but I blame this list for constantly responding to the TROLL and FEEDING it. DONT DO IT
I raise the simple motion that when Nicholas Krause posts - NOBODY responds to him - EVER - under threat of torture or whatever - for whatever reason - my joy of lurking here has been ruined by a single IDIOT - if this was nntp he would have wandered off a long time ago with ignores - but I blame this list for constantly responding to the TROLL and FEEDING it. DONT DO IT
Couldn't agree more. Just don't.
Adrian Cornish <adrianc <at> cqg.com> writes:
I raise the simple motion that when Nicholas Krause posts - NOBODY responds to him - EVER - under threat of torture or whatever - for whatever reason - my joy of lurking here has been ruined by a single IDIOT - if this was nntp he would have wandered off a long time ago with ignores - but I blame this list for constantly responding to the TROLL and FEEDING it. DONT DO IT
Unfortunately this isn't the time of NNTP, and since lkml (and newbies) always was a mailing list, the only hope is in respective peoples' killfiles... We need to assume that the list is being watched not only by technically able people, but also by ones who have just a filter for [PATCH] and don't always get the difference between Reviewed-by and Acked-by... AND some that could assume that no-answer to a [PATCH] equals silent acceptance ... Or if he's con enough, he could say, oh see all the patches I submitted, no one ever said anything against them... (and as Greg K-H once said, a few /accepted/ patches can make someone employed...) Maybe better to introduce a standard clear marker that able people just respond with, to alikes of nick: REJECTED-by: Name <address@email.server> single line, maybe add 1 line of technical explanation and DO NOT react* to any further emails demanding further explanation. (* e.g. place on kill file in your private MUA, so the only way they can ever get un-ignored is IFF they submit VALID patches to public list AND they get at least Acked.). (Rationale: REJECTED, because Nacked-by contains the 'acked' word... too easy to overlook. CAPITALS because they do stand out. REJECTED also is clear in intent in any english<->native dictionary, REJECTED is (IMO) also a strong enough word to not need any further emotional emits... It's NOT intended in the way the April Fools like/dislike patches on Facebook was suggested. Nothing to emotionally react to, just a signal that THIS PATCH IS NOT GOING TO BE APPLIED. Also it's a serious word, contrary to Trash-detected-by or This-is-BS-by or Stay-away-from-my-list-by... Only to be used as 'last resort' if someone repeatedly fails sanity test. Because alternative is, that the mailing list(s) become invite-only, and that is not going to happen. ) el_es
On Mon, 20 Oct 2014 09:17:50 -0000, el_es said:
Maybe better to introduce a standard clear marker that able people just respond with, to alikes of nick:
REJECTED-by: Name <address@email.server>
We already do something like this. You'll on occasion see 'Nacked-By: ...' go by when a kernel hacker wants to denote their displeasure with a given patch. It's up to the maintainer to decide how much credence to give to the Nack, based on the relative reputations of the person submitting the patch and the person nacking it, and any technical grounds given with the nack. So for instance, if Al Viro sticks a Nacked-By: on a submission, it's going to be *really* hard to get a maintainer to accept the patch, because Al has a very long history of almost always being right about such things.
Valdis.Kletnieks@vt.edu writes:
On Mon, 20 Oct 2014 09:17:50 -0000, el_es said:
Maybe better to introduce a standard clear marker that able people just respond with, to alikes of nick:
REJECTED-by: Name <address@email.server>
We already do something like this.
You'll on occasion see 'Nacked-By: ...' go by when a kernel hacker wants to denote their displeasure with a given patch. It's up to the maintainer to decide how much credence to give to the Nack, based on the relative reputations of the person submitting the patch and the person nacking it, and any technical grounds given with the nack.
So for instance, if Al Viro sticks a Nacked-By: on a submission, it's going to be *really* hard to get a maintainer to accept the patch, because Al has a very long history of almost always being right about such things.
Yes, but the technical grounds are still the reason the patch is not accepted. Which is why a formalized nak is pointless. It has no value without a verbose explanation of the technical grounds behind it. If Al Viro, or anyone else, use a simple one-line reject message, then I am pretty sure that is because they have already explained their objections somewhere else. I don't think anyone can reject anything merely on their personal reputation. And there is nowhere to record naks, so a standard label just isn't needed. Rejecting is completely different from e.g. Acked-by, which both is a complete explanation ("I am fine with this patch as it is") and is recorded for future reference in the commit message. Bjørn
Greetings Bjorn and others, I sent this patch a few weeks ago and am really trying to to improve my rep here by sending solid patches. In addition I understand the caution with my patches due to my terrible rep but it would be nice if someone sends or acknowledges the patch as other people on this list have stated it's correct and good in previous emails to me. Nick On 14-11-03 05:05 AM, Bjørn Mork wrote:
Valdis.Kletnieks@vt.edu writes:
On Mon, 20 Oct 2014 09:17:50 -0000, el_es said:
Maybe better to introduce a standard clear marker that able people just respond with, to alikes of nick:
REJECTED-by: Name <address@email.server>
We already do something like this.
You'll on occasion see 'Nacked-By: ...' go by when a kernel hacker wants to denote their displeasure with a given patch. It's up to the maintainer to decide how much credence to give to the Nack, based on the relative reputations of the person submitting the patch and the person nacking it, and any technical grounds given with the nack.
So for instance, if Al Viro sticks a Nacked-By: on a submission, it's going to be *really* hard to get a maintainer to accept the patch, because Al has a very long history of almost always being right about such things.
Yes, but the technical grounds are still the reason the patch is not accepted. Which is why a formalized nak is pointless. It has no value without a verbose explanation of the technical grounds behind it. If Al Viro, or anyone else, use a simple one-line reject message, then I am pretty sure that is because they have already explained their objections somewhere else. I don't think anyone can reject anything merely on their personal reputation. And there is nowhere to record naks, so a standard label just isn't needed.
Rejecting is completely different from e.g. Acked-by, which both is a complete explanation ("I am fine with this patch as it is") and is recorded for future reference in the commit message.
Bjørn
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Sat, 11 Oct 2014, nick wrote:
Thank you for your help, I'll study the code and see what I can do about it. Do you have any suggestions of how to fix this checkpatch warning?
there is absolutely nothing wrong with that code -- the problem is your utter lack of understanding. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
participants (15)
-
Adrian Cornish -
Bjørn Mork -
Dave Tian -
el_es -
Hugo Mills -
John de la Garza -
karthik nayak -
Kernel Apprentice -
Kristofer Hallin -
Nicholas Krause -
nick
-
Peter Senna Tschudin -
Robert P. J. Day -
Sudip Mukherjee -
Valdis.Kletnieks＠vt.edu