Eudyptula Challenge (Task 10)

Eudyptula Challenge (Task 10)

[Wahib Faizi]

Greetings Linux Kernel Developers!

This is Task 10 of the Eudyptula Challenge.

[PATCH] drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c: fix coding style

[Wahib Faizi]

Fix coding style issues detected by checkpatch.pl:
1. do not use assignment in if condition
2. line over 80 characters

Signed-off-by: Wahib Faizi <wahibfaizi@gmail.com>
---
 .../usbip/userspace/libsrc/usbip_host_driver.c     |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
index 92caef7..bef08d5 100644
--- a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
+++ b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
@@ -47,7 +47,8 @@ static int32_t read_attr_usbip_status(struct usbip_usb_device *udev)
 	snprintf(status_attr_path, SYSFS_PATH_MAX, "%s/usbip_status",
 		 udev->path);
 
-	if ((fd = open(status_attr_path, O_RDONLY)) < 0) {
+	fd = open(status_attr_path, O_RDONLY);
+	if (fd < 0) {
 		err("error opening attribute %s", status_attr_path);
 		return -1;
 	}
@@ -87,8 +88,8 @@ struct usbip_exported_device *usbip_exported_device_new(const char *sdevpath)
 		goto err;
 
 	/* reallocate buffer to include usb interface data */
-	size = sizeof(struct usbip_exported_device) + edev->udev.bNumInterfaces *
-		sizeof(struct usbip_usb_interface);
+	size = sizeof(struct usbip_exported_device) +
+		edev->udev.bNumInterfaces * sizeof(struct usbip_usb_interface);
 
 	edev_old = edev;
 	edev = realloc(edev, size);
-- 
1.7.9.5

Re: [PATCH] drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c: fix coding style

[Greg Kroah-Hartman]

On Thu, Jun 12, 2014 at 02:35:38PM +0400, Wahib Faizi wrote:
> Fix coding style issues detected by checkpatch.pl:
> 1. do not use assignment in if condition
> 2. line over 80 characters

You are doing two different things here, so please break it up into two
different patches.  Can you please do this and resend?

thanks,

greg k-h

Split patch into 2 logical chunks

[Wahib Faizi]

Fix coding style issues detected by checkpatch.pl in usbip_host_driver.c.

v2: Split patch into logical chunks, as suggested by 
    Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[PATCH v2 1/2]
Fix coding style issue "do not use assignment in if condition" 
detected by checkpatch.pl in usbip_host_driver.c.

[PATCH v2 2/2]
Fix coding style issue "line over 80 characters" 
detected by checkpatch.pl in usbip_host_driver.c.

[PATCH v2 1/2] drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c: fix coding style

[Wahib Faizi]

Fix coding style issue "do not use assignment in if condition"
detected by checkpatch.pl in usbip_host_driver.c.

Signed-off-by: Wahib Faizi <wahibfaizi@gmail.com>
---
 .../usbip/userspace/libsrc/usbip_host_driver.c     |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
index 92caef7..32b8f52 100644
--- a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
+++ b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
@@ -47,7 +47,8 @@ static int32_t read_attr_usbip_status(struct usbip_usb_device *udev)
 	snprintf(status_attr_path, SYSFS_PATH_MAX, "%s/usbip_status",
 		 udev->path);
 
-	if ((fd = open(status_attr_path, O_RDONLY)) < 0) {
+	fd = open(status_attr_path, O_RDONLY);
+	if (fd < 0) {
 		err("error opening attribute %s", status_attr_path);
 		return -1;
 	}
-- 
1.7.9.5

[PATCH v2 2/2] drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c: fix coding style

[Wahib Faizi]

Fix coding style issue "line over 80 characters"
detected by checkpatch.pl in usbip_host_driver.c.

Signed-off-by: Wahib Faizi <wahibfaizi@gmail.com>
---
 .../usbip/userspace/libsrc/usbip_host_driver.c     |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
index 32b8f52..bef08d5 100644
--- a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
+++ b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
@@ -88,8 +88,8 @@ struct usbip_exported_device *usbip_exported_device_new(const char *sdevpath)
 		goto err;
 
 	/* reallocate buffer to include usb interface data */
-	size = sizeof(struct usbip_exported_device) + edev->udev.bNumInterfaces *
-		sizeof(struct usbip_usb_interface);
+	size = sizeof(struct usbip_exported_device) +
+		edev->udev.bNumInterfaces * sizeof(struct usbip_usb_interface);
 
 	edev_old = edev;
 	edev = realloc(edev, size);
-- 
1.7.9.5

Re: [PATCH v2 1/2] drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c: fix coding style

[Greg Kroah-Hartman]

On Thu, Jun 12, 2014 at 09:32:19PM +0400, Wahib Faizi wrote:
> Fix coding style issue "do not use assignment in if condition"
> detected by checkpatch.pl in usbip_host_driver.c.
> 
> Signed-off-by: Wahib Faizi <wahibfaizi@gmail.com>

Both of these patches have the same Subject: line, which isn't good as
it doesn't make much sense.

You can also shorten it a lot, for example, this one should be:
  Subject: staging: usbip: usbip_host_driver.c: fix if assignment style issue

Care to redo both of these that way?

thanks,

greg k-h

Re: [PATCH v2 1/2] drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c: fix coding style

[Joe Perches]

On Thu, 2014-06-12 at 10:54 -0700, Greg Kroah-Hartman wrote:
> On Thu, Jun 12, 2014 at 09:32:19PM +0400, Wahib Faizi wrote:
> > Fix coding style issue "do not use assignment in if condition"
> > detected by checkpatch.pl in usbip_host_driver.c.
> > 
> > Signed-off-by: Wahib Faizi <wahibfaizi@gmail.com>
> 
> Both of these patches have the same Subject: line, which isn't good as
> it doesn't make much sense.
> 
> You can also shorten it a lot, for example, this one should be:
>   Subject: staging: usbip: usbip_host_driver.c: fix if assignment style issue

True.  usbip_host_driver.c doesn't add much though.

It could even be something like:

staging: usbip: avoid assignment in if

Fix subject line

[Wahib Faizi]

Fix coding style issues detected by checkpatch.pl in usbip_host_driver.c.

v3: Shorten subject line, as suggested by
    Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
    Joe Perches <joe@perches.com>
 
v2: Split patch into logical chunks, as suggested by
    Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[PATCH 1/2] staging: usbip: usbip_host_driver.c: avoid assignment in if

[Wahib Faizi]

Fix coding style issue "do not use assignment in if condition"
detected by checkpatch.pl in usbip_host_driver.c.

Signed-off-by: Wahib Faizi <wahibfaizi@gmail.com>
---
 .../usbip/userspace/libsrc/usbip_host_driver.c     |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
index 92caef7..32b8f52 100644
--- a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
+++ b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
@@ -47,7 +47,8 @@ static int32_t read_attr_usbip_status(struct usbip_usb_device *udev)
 	snprintf(status_attr_path, SYSFS_PATH_MAX, "%s/usbip_status",
 		 udev->path);
 
-	if ((fd = open(status_attr_path, O_RDONLY)) < 0) {
+	fd = open(status_attr_path, O_RDONLY);
+	if (fd < 0) {
 		err("error opening attribute %s", status_attr_path);
 		return -1;
 	}
-- 
1.7.9.5

[PATCH 2/2] staging: usbip: usbip_host_driver.c: fix line over 80 characters

[Wahib Faizi]

Fix coding style issue "line over 80 characters"
detected by checkpatch.pl in usbip_host_driver.c.

Signed-off-by: Wahib Faizi <wahibfaizi@gmail.com>
---
 .../usbip/userspace/libsrc/usbip_host_driver.c     |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
index 32b8f52..bef08d5 100644
--- a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
+++ b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
@@ -88,8 +88,8 @@ struct usbip_exported_device *usbip_exported_device_new(const char *sdevpath)
 		goto err;
 
 	/* reallocate buffer to include usb interface data */
-	size = sizeof(struct usbip_exported_device) + edev->udev.bNumInterfaces *
-		sizeof(struct usbip_usb_interface);
+	size = sizeof(struct usbip_exported_device) +
+		edev->udev.bNumInterfaces * sizeof(struct usbip_usb_interface);
 
 	edev_old = edev;
 	edev = realloc(edev, size);
-- 
1.7.9.5

[PATCH v3 0/2] Fix subject line

[Wahib Faizi]

Fix coding style issues detected by checkpatch.pl in usbip_host_driver.c.

v3: Shorten subject line, as suggested by 
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Joe Perches <joe@perches.com>

v2: Split patch into logical chunks, as suggested by 
Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[PATCH v3 1/2] staging: usbip: usbip_host_driver.c: avoid assignment in if

[Wahib Faizi]

Fix coding style issue "do not use assignment in if condition"
detected by checkpatch.pl in usbip_host_driver.c.

Signed-off-by: Wahib Faizi <wahibfaizi@gmail.com>
---
 .../usbip/userspace/libsrc/usbip_host_driver.c     |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
index 92caef7..32b8f52 100644
--- a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
+++ b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
@@ -47,7 +47,8 @@ static int32_t read_attr_usbip_status(struct usbip_usb_device *udev)
 	snprintf(status_attr_path, SYSFS_PATH_MAX, "%s/usbip_status",
 		 udev->path);
 
-	if ((fd = open(status_attr_path, O_RDONLY)) < 0) {
+	fd = open(status_attr_path, O_RDONLY);
+	if (fd < 0) {
 		err("error opening attribute %s", status_attr_path);
 		return -1;
 	}
-- 
1.7.9.5

[PATCH v3 2/2] staging: usbip: usbip_host_driver.c: fix line over 80 characters

[Wahib Faizi]

Fix coding style issue "line over 80 characters"
detected by checkpatch.pl in usbip_host_driver.c.

Signed-off-by: Wahib Faizi <wahibfaizi@gmail.com>
---
 .../usbip/userspace/libsrc/usbip_host_driver.c     |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
index 32b8f52..bef08d5 100644
--- a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
+++ b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
@@ -88,8 +88,8 @@ struct usbip_exported_device *usbip_exported_device_new(const char *sdevpath)
 		goto err;
 
 	/* reallocate buffer to include usb interface data */
-	size = sizeof(struct usbip_exported_device) + edev->udev.bNumInterfaces *
-		sizeof(struct usbip_usb_interface);
+	size = sizeof(struct usbip_exported_device) +
+		edev->udev.bNumInterfaces * sizeof(struct usbip_usb_interface);
 
 	edev_old = edev;
 	edev = realloc(edev, size);
-- 
1.7.9.5

Re: [PATCH v3 0/2] Fix subject line

[Davidlohr Bueso]

On Thu, 2014-06-12 at 23:40 +0400, Wahib Faizi wrote:
> Fix coding style issues detected by checkpatch.pl in usbip_host_driver.c.

Sorry but unless bundled with something more meaningful, I really don't
see the value in these changes. I certainly don't want to discourage
folks or anything, but just testing other patches is a lot more helpful
than this. 

I haven't followed much about the Eudyptula Challenge, but I hope other
assignments are more involved than this.

Thanks,
Davidlohr

Re: [PATCH v3 0/2] Fix subject line

[Greg Kroah-Hartman]

On Thu, Jun 12, 2014 at 01:25:34PM -0700, Davidlohr Bueso wrote:
> On Thu, 2014-06-12 at 23:40 +0400, Wahib Faizi wrote:
> > Fix coding style issues detected by checkpatch.pl in usbip_host_driver.c.
> 
> Sorry but unless bundled with something more meaningful, I really don't
> see the value in these changes. I certainly don't want to discourage
> folks or anything, but just testing other patches is a lot more helpful
> than this. 

When the staging code is still needing basic fixes like this, it is
"meaningful" to do patches that clean up stuff like this.  That's what
the staging tree is for.

thanks,

greg k-h

Re: [PATCH v3 0/2] Fix subject line

[Davidlohr Bueso]

On Thu, 2014-06-12 at 13:35 -0700, Greg Kroah-Hartman wrote:
> On Thu, Jun 12, 2014 at 01:25:34PM -0700, Davidlohr Bueso wrote:
> > On Thu, 2014-06-12 at 23:40 +0400, Wahib Faizi wrote:
> > > Fix coding style issues detected by checkpatch.pl in usbip_host_driver.c.
> > 
> > Sorry but unless bundled with something more meaningful, I really don't
> > see the value in these changes. I certainly don't want to discourage
> > folks or anything, but just testing other patches is a lot more helpful
> > than this. 
> 
> When the staging code is still needing basic fixes like this, it is
> "meaningful" to do patches that clean up stuff like this.  That's what
> the staging tree is for.

Sure, but "making checkpatch happy just to make checkpatch happy" isn't
a good justification, even for staging. Patch 1 does have value in that
it helps avoid silly bugs, but take patch 2/2, we end-up saving just a
few spaces... Anyways, just my 2 cents.

Thanks,
Davidlohr

Re: [PATCH v3 0/2] Fix subject line

[Dan Carpenter]

On Thu, Jun 12, 2014 at 01:48:38PM -0700, Davidlohr Bueso wrote:
> On Thu, 2014-06-12 at 13:35 -0700, Greg Kroah-Hartman wrote:
> > On Thu, Jun 12, 2014 at 01:25:34PM -0700, Davidlohr Bueso wrote:
> > > On Thu, 2014-06-12 at 23:40 +0400, Wahib Faizi wrote:
> > > > Fix coding style issues detected by checkpatch.pl in usbip_host_driver.c.
> > > 
> > > Sorry but unless bundled with something more meaningful, I really don't
> > > see the value in these changes. I certainly don't want to discourage
> > > folks or anything, but just testing other patches is a lot more helpful
> > > than this. 
> > 
> > When the staging code is still needing basic fixes like this, it is
> > "meaningful" to do patches that clean up stuff like this.  That's what
> > the staging tree is for.
> 
> Sure, but "making checkpatch happy just to make checkpatch happy" isn't
> a good justification, even for staging.

It actually is.  Fighting against checkpatch is a losers battle.  Our
way more efficient.

1) We do need to fix this checkpatch warning before it moves out of
   staging.
2) NAKing patches is actually a lot of stress for everyone.  It stresses
   out submitters and drives them away.  It stresses out the
   maintainers because we feel bad.  That stress is bad when it is
   pointless.
3) This patch is ok.
4) If we don't apply this patch then someone else will send the exact
   same patch or something worse until we apply something.
5) The v3 of this patch takes under 30 seconds to review and apply.
6) Newbies feel happy when their patch gets merged and that is good.

The other thing is that if you start asking "Is this patch meaningful"
then it makes applying any patch into a big question about meaning and
it tires you out.

In staging we have clear rules for when a patch is going to be applied
and everyone understands the rules.  It means that if Greg is traveling
then you know which patches he is going to apply in what order and life
is easier because it is more predictable.

regards,
dan carpenter

Re: [PATCH v3 0/2] Fix subject line

[Wahib]

Hi Davidlohr!

Don't worry. I am not discouraged. :)

I understand your concern that the patch feels superficial. It's what the task
asked us to do. I suspect the author(s) of the Eudyptula Challenge designed
this task to get us involved with the Linux kernel community.

I have been looking for a bug in 'usbip' to bundle with my patch. The only bug
that I could find (as of 16-Jun-2014) on bugzilla.kernel.org related
to 'usbip' is Bug 77191.

Bug 77191 - ftdi-sio (usbserial) over usbip hung after disconnect while in use
(https://bugzilla.kernel.org/show_bug.cgi?id=77191)

Sadly the bug doesn't seem to be newbie friendly as it requires special setup
to reproduce and requires the developer to know about the intricacies of the
'usbip' subsystem. I understand that people commiting their specialized
knowledge is how the kernel development actually works. But USB is not my
speciality (yet).

Could you point me to more beginner friendly bugs which aren't superficial code
cleanups?

Can I bundle fixes to subsystems other than 'usbip' with the code cleanup patch
for 'usbip'?

Regards,
Wahib

On Fri, Jun 13, 2014 at 12:25 AM, Davidlohr Bueso <davidlohr@hp.com> wrote:
> On Thu, 2014-06-12 at 23:40 +0400, Wahib Faizi wrote:
>> Fix coding style issues detected by checkpatch.pl in usbip_host_driver.c.
>
> Sorry but unless bundled with something more meaningful, I really don't
> see the value in these changes. I certainly don't want to discourage
> folks or anything, but just testing other patches is a lot more helpful
> than this.
>
> I haven't followed much about the Eudyptula Challenge, but I hope other
> assignments are more involved than this.
>
> Thanks,
> Davidlohr
>

Re: [PATCH v3 0/2] Fix subject line

[Davidlohr Bueso]

On Mon, 2014-06-16 at 00:28 +0400, Wahib wrote:
> Hi Davidlohr!
> 
> Don't worry. I am not discouraged. :)
> 
> I understand your concern that the patch feels superficial. It's what the task
> asked us to do. I suspect the author(s) of the Eudyptula Challenge designed
> this task to get us involved with the Linux kernel community.

If you feel you actually learn something by doing the Eudyptula
Challenge, then good for you, and by all means continue doing so. As I
mentioned, I know almost zero about it, but can say for sure that
cleanups alone won't get you very far in the community and you will
probably get bored sooner or later -- which is unfortunate as kernel
hacking fascinating.

> 
> I have been looking for a bug in 'usbip' to bundle with my patch. The only bug
> that I could find (as of 16-Jun-2014) on bugzilla.kernel.org related
> to 'usbip' is Bug 77191.
> 
> Bug 77191 - ftdi-sio (usbserial) over usbip hung after disconnect while in use
> (https://bugzilla.kernel.org/show_bug.cgi?id=77191)
> 
> Sadly the bug doesn't seem to be newbie friendly as it requires special setup
> to reproduce and requires the developer to know about the intricacies of the
> 'usbip' subsystem. I understand that people commiting their specialized
> knowledge is how the kernel development actually works. But USB is not my
> speciality (yet).
> 
> Could you point me to more beginner friendly bugs which aren't superficial code
> cleanups?

There are plenty of bugs out there, and not so hard to find -- just push
some module/filesystem/subsystem/testcase hard enough to make it do
things it shouldn't. Run linux-next on trinity and fix/report the bugs,
etc.

imho testing and reading other people's patches is perhaps the best way
to do useful things, get acquainted with the code and get experience
with lkml and the process behind kernel development.

> Can I bundle fixes to subsystems other than 'usbip' with the code cleanup patch
> for 'usbip'?

Probably not, unless it's a tree-wide change.

Hope this helps,
Davidlohr

Re: Eudyptula Challenge (Task 10)

[Jason Cooper]

On Mon, Jul 28, 2014 at 05:53:19AM -0700, Christoph Hellwig wrote:
> Can you folks please stop this challenge Bullshit?  More checkpatch
> fixes is not something we'll need at all.

Greg and Dan have previously said that the staging tree is a good place
for newcomers to submit checkpatch cleanup patches.  However, I think
there are a few tweaks that could be made to the Eudyptula Challenge to
avoid this noise/frustration:

  - No need to send to lkml, the staging tree ML is probably fine.

  - Don't mention Eudyptula Challenge, it's not relevant to the patch.
     * It looks like you want a cookie.  We have none.

  - Submit the patch to the Challenge admins first for review.  This
    patch submission should have never made the cut.
     - No S-o-B
     - MIME attachment
     - Subject line is just wrong
     - Full name missing in From:

I've worked with several participants of the challenge and never saw
this many things wrong with a patch submission.  Either the admins are
dropping the ball, or this participant got loose somehow. :)

It makes me wonder if they should start with a git workflow from day
one?  It would prevent a lot of these avoidable mistakes.

thx,

Jason.

Re: Eudyptula Challenge (Task 10)

[Denis Kirjanov]

On 7/28/14, Lucas Tanure <tanure@linux.com> wrote:
> Hi Christoph,
>
> What kind of things that you think a newbie can fix ?

You can start working on fixing the pci_map_* and dma_map_* return
value checks with CONFIG_DMA_API_DEBUG enabled. A lot of drivers still
missing that...

> Thanks
> --
> Lucas Tanure
> +55 (19) 988176559
>
>
> On Mon, Jul 28, 2014 at 9:53 AM, Christoph Hellwig <hch@infradead.org>
> wrote:
>> Can you folks please stop this challenge Bullshit?  More checkpatch
>> fixes is not something we'll need at all.
>>
>> Thanks you!
>>
>> --
>> 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/
> _______________________________________________
> devel mailing list
> devel@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
>


-- 
Regards,
Denis

Re: Eudyptula Challenge (Task 10)

[Lucas Tanure]

Hi Christoph,

What kind of things that you think a newbie can fix ?

Thanks
--
Lucas Tanure
+55 (19) 988176559


On Mon, Jul 28, 2014 at 9:53 AM, Christoph Hellwig <hch@infradead.org> wrote:
> Can you folks please stop this challenge Bullshit?  More checkpatch
> fixes is not something we'll need at all.
>
> Thanks you!
>
> --
> 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/

Re: Eudyptula Challenge (Task 10)

[Christoph Hellwig]

Can you folks please stop this challenge Bullshit?  More checkpatch
fixes is not something we'll need at all.

Thanks you!

Re: Eudyptula Challenge (Task 10)

[Dan Carpenter]

Fix your From header and read paragraph 1 of
Documentation/email-clients.txt

regards,
dan carpenter

Eudyptula Challenge (Task 10)

[Liviu I.]

[-- Attachment #1: Type: text/plain, Size: 214 bytes --]

Hello Kernel Developers!

I've attached a small patch to fix a coding style problem and make checkpatch happy, as part of challenge 10 of Eudyptula.

Signed-off-by: Liviu Itoafa <liviu.i.2222@gmail.com>

Thank you

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 444 bytes --]

--- drivers/staging/lustre/lustre/ldlm/ldlm_extent.c.orig	2014-07-27 20:26:53.714161698 +0100
+++ drivers/staging/lustre/lustre/ldlm/ldlm_extent.c	2014-07-27 20:27:50.410159692 +0100
@@ -151,7 +151,8 @@ static inline int lock_mode_to_index(ldl
 
 	LASSERT(mode != 0);
 	LASSERT(IS_PO2(mode));
-	for (index = -1; mode; index++, mode >>= 1) ;
+	for (index = -1; mode; index++, mode >>= 1)
+		;
 	LASSERT(index < LCK_MODE_NUM);
 	return index;
 }

Re: Eudyptula Challenge (Task 10)

[Greg KH]

On Sun, Jul 27, 2014 at 08:56:38PM +0100, Liviu I. wrote:
> Hello Kernel Developers!
> 
> I've attached a small patch to fix a coding style problem and make checkpatch happy, as part of challenge 10 of Eudyptula.
> 
> Thank you

> --- drivers/staging/lustre/lustre/ldlm/ldlm_extent.c.orig	2014-07-27 20:26:53.714161698 +0100
> +++ drivers/staging/lustre/lustre/ldlm/ldlm_extent.c	2014-07-27 20:27:50.410159692 +0100
> @@ -151,7 +151,8 @@ static inline int lock_mode_to_index(ldl
>  
>  	LASSERT(mode != 0);
>  	LASSERT(IS_PO2(mode));
> -	for (index = -1; mode; index++, mode >>= 1) ;
> +	for (index = -1; mode; index++, mode >>= 1)
> +		;
>  	LASSERT(index < LCK_MODE_NUM);
>  	return index;
>  }

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch does not have a Signed-off-by: line.  Please read the
  kernel file, Documentation/SubmittingPatches and resend it after
  adding that line.  Note, the line needs to be in the body of the
  email, before the patch, not at the bottom of the patch or in the
  email signature.

- You did not specify a description of why the patch is needed, or
  possibly, any description at all, in the email body.  Please read the
  section entitled "The canonical patch format" in the kernel file,
  Documentation/SubmittingPatches for what is needed in order to
  properly describe the change.

- You did not write a descriptive Subject: for the patch, allowing Greg,
  and everyone else, to know what this patch is all about.  Please read
  the section entitled "The canonical patch format" in the kernel file,
  Documentation/SubmittingPatches for what a proper Subject: line should
  look like.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot

Eudyptula Challenge (Task 10)

[Liviu I.]

[-- Attachment #1: Type: text/plain, Size: 160 bytes --]

Hello Kernel Developers!

I've attached a small patch to fix a coding style problem and make checkpatch happy, as part of challenge 10 of Eudyptula.

Thank you

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 444 bytes --]

--- drivers/staging/lustre/lustre/ldlm/ldlm_extent.c.orig	2014-07-27 20:26:53.714161698 +0100
+++ drivers/staging/lustre/lustre/ldlm/ldlm_extent.c	2014-07-27 20:27:50.410159692 +0100
@@ -151,7 +151,8 @@ static inline int lock_mode_to_index(ldl
 
 	LASSERT(mode != 0);
 	LASSERT(IS_PO2(mode));
-	for (index = -1; mode; index++, mode >>= 1) ;
+	for (index = -1; mode; index++, mode >>= 1)
+		;
 	LASSERT(index < LCK_MODE_NUM);
 	return index;
 }