All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Jeremy White <jwhite@codeweavers.com>, Greg KH <greg@kroah.com>
Cc: spice-devel@lists.freedesktop.org, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 1/1] Add a usbredir kernel module to remotely connect USB devices over IP.
Date: Wed, 8 Jul 2015 09:11:53 +0200	[thread overview]
Message-ID: <559CCD39.90606@redhat.com> (raw)
In-Reply-To: <559C0285.6090509@codeweavers.com>

Hi,

On 07-07-15 18:47, Jeremy White wrote:
>
>>>
>>> Well, the checkpatch.pl reports were all style (and mostly whitespace);
>>> roughly 3000 of them against 3000 lines of code :-/.  I did review the
>>> code, looking for areas where I thought it would badly cram into the
>>> kernel, and I adjusted the few I found (and sent changes upstream).
>>
>> style matters, as it's a thing with your brain.  You learn patterns and
>> if the patterns change, you have to do more work and don't see the real
>> issues involved.  So by ignoring our style you are saying you don't want
>> anyone else in the kernel community to ever review or work on the code,
>> which isn't ok.
>
> Looks like I can't side step this unless Hans is willing to shift the
> usbredir project entirely to using kernel style :-/.

I'm fine with moving the usbredir project to the kernel style, the question
is how to do this without causing any hidden breakage.

Can you create a gnu-indent invocation which will do most of the work?

And then a hopefully managable sized patch on top to fix the remaining
style errors in usbredirparser ?

> I will plan to make changes so that checkpatch runs clean; I lay out my
> concerns and my plan below to make sure I'm taking the best path.
>
> My main concern with changing the ~2,500 lines of code from the upstream
> usbredir project is that it will increase the odds that I will introduce
> errors, both initially, and again later as I review and attempt to relay
> patches from the upstream.
>
> To summarize the checkpatch reports:  the biggest issue is whitespace,
> which shouldn't be a problem; I should be able to automate that without
> error.  There are also a fair number of one offs; FSF address, space
> after '!', etc.  I hope to persuade Hans to take a few style only
> patches upstream to address those.  That leaves a pack of about 60 brace
> placement and line length issues.
>
> I will plan to manually change those prior to submission.  Any upstream
> changes that affect the same code will be manually corrected as well,
> prior to submission.
>
> Make sense?

Sounds good, note that as said I'm fine with moving over the usbredir(parser)
code to the kernel style, as long as the changes are reviewable.

I think it may be best to only convert the usbredirdparser files, as those
are the only ones you need for the kernel. Having a mixed style in usbredir
is not ideal, but something I can live with.

Regards,

Hans


  reply	other threads:[~2015-07-08  7:12 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-30 21:44 [RFC PATCH 0/1] RFC - Implement a usbredir kernel module Jeremy White
2015-06-30 21:44 ` [RFC PATCH 1/1] Add a usbredir kernel module to remotely connect USB devices over IP Jeremy White
2015-06-30 23:48   ` Greg KH
2015-07-01  3:34     ` Jeremy White
2015-07-01  5:44       ` Greg KH
2015-07-01 15:55         ` Jeremy White
2015-07-01 16:13           ` Greg KH
2015-07-01 18:39             ` Hans de Goede
2015-07-07 16:47             ` Jeremy White
2015-07-08  7:11               ` Hans de Goede [this message]
2015-07-09  0:19                 ` Jeremy White
2015-07-01  9:06   ` [Spice-devel] " Daniel P. Berrange
2015-07-01 18:31     ` Jeremy White
2015-07-01 18:45       ` Hans de Goede
2015-07-02  8:45     ` Oliver Neukum
2015-07-02 11:35       ` Hans de Goede
2015-07-02 12:10         ` Oliver Neukum
2015-07-02 15:57           ` Jeremy White
2015-07-02 18:46             ` Oliver Neukum
2015-07-02 19:02               ` Jeremy White
2015-07-02 19:59                 ` Alan Stern
2015-07-02 20:06                   ` Jeremy White
2015-07-02 20:20                     ` Alan Stern
2015-07-03  8:51                       ` Krzysztof Opasiak
2015-07-03 14:04                         ` Alan Stern
2015-07-06  8:20                         ` Oliver Neukum
2015-07-06 20:14                           ` Jeremy White
2015-07-06 20:22                             ` Alan Stern
     [not found]                               ` <mnlh2b$1cs$1@ger.gmane.org>
2015-07-22 14:03                                 ` Jeremy White
2015-07-22 14:34                                   ` Greg KH
2015-07-22 16:55                                     ` Jeremy White
2015-07-22 17:59                                       ` Sean O. Stalley
2015-07-23  0:20                                         ` Jeremy White
2015-12-09 22:32                                           ` Jeremy White

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=559CCD39.90606@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=greg@kroah.com \
    --cc=jwhite@codeweavers.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=spice-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.