From: Greg KH <greg@kroah.com>
To: matt mooney <mfmooney@gmail.com>
Cc: linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH 00/12] staging: usbip: miscellaneous code cleanup
Date: Wed, 11 May 2011 16:18:43 -0700 [thread overview]
Message-ID: <20110511231843.GC7362@kroah.com> (raw)
In-Reply-To: <BANLkTikjf9ZAthr3jTUkoUKGJt2UGS73Cg@mail.gmail.com>
On Wed, May 11, 2011 at 04:08:07PM -0700, matt mooney wrote:
> On Wed, May 11, 2011 at 2:14 PM, Greg KH <greg@kroah.com> wrote:
> > On Wed, May 11, 2011 at 01:54:12AM -0700, matt mooney wrote:
> >> Hi Greg,
> >>
> >> I am interested in hearing your thoughts on the userspace interface?
> >
> > Which one? The user/kernel interface?
>
> Yes.
>
> >
> >> Even as is, it definitely needs some work. For one thing I was thinking
> >> of removing the debug flag from userspace. The userspace utilites are
> >> not using it anyway, and it is not 100% working yet.
> >
> > I haven't looked at the interface much yet, what is your issue with the
> > debug flag?
>
> I guess it just added a lot of code (most was actually eliminated in
> the pr_*() change), is not complete, and is inconsistently used. But I
> see that it would be helpful especially due to the amount of debug
> messages printed by default. So ignore that complaint.
Ok.
> > To make things easier, and allow you to be able to change the userspace
> > interface, I suggest moving the userspace code into the kernel tree, and
> > building it here. That would allow you to move forward with changing
> > things easier, doing it all in one place allows you to keep stuff in
> > sync, and provides people an easier way to actually get the needed tools
> > to drive the code.
> >
> > What do you think about doing that?
>
> Sure, I didn't even know that was an option. How do you propose that
> is done though?
We add it to drivers/staging/usbip/userspace/ and build it like the perf
code is built.
> > I've applied a number of these patches, care to respin the others and
> > resend them based on my latest tree?
>
> Okay, I will do that. I noticed some were missed but that may be
> because they depended on a few of the unapplied ones anyway, so I will
> also resend those as well.
Yes, they couldn't be applied so I didn't.
thanks,
greg k-h
next prev parent reply other threads:[~2011-05-11 23:19 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-11 8:54 [PATCH 00/12] staging: usbip: miscellaneous code cleanup matt mooney
2011-05-11 8:54 ` [PATCH 01/12] staging: usbip: change debug configuration option matt mooney
2011-05-11 8:54 ` [PATCH 02/12] staging: usbip: use single version for all modules matt mooney
2011-05-11 8:54 ` [PATCH 03/12] staging: usbip: fix header includes matt mooney
2011-05-11 21:07 ` Greg KH
2011-05-11 22:54 ` matt mooney
2011-05-11 8:54 ` [PATCH 04/12] staging: usbip: replace usbip_u{dbg,err,info} and printk with pr_ equivalent matt mooney
2011-05-11 21:06 ` Greg KH
2011-05-11 22:51 ` matt mooney
2011-05-11 23:19 ` Greg KH
2011-05-11 8:54 ` [PATCH 05/12] staging: usbip: remove unnecessary lines and extra return statements matt mooney
2011-05-11 8:54 ` [PATCH 06/12] staging: usbip: stub_main.c: code cleanup matt mooney
2011-05-11 21:08 ` Greg KH
2011-05-11 22:56 ` matt mooney
2011-05-11 8:54 ` [PATCH 07/12] staging: usbip: stub_main.c: change __init/__exit prefix and use KMEM_CACHE matt mooney
2011-05-11 8:54 ` [PATCH 08/12] staging: usbip: usbip_common.c: fix misspelled function name matt mooney
2011-05-11 8:54 ` [PATCH 09/12] staging: usbip: edit Kconfig and rename CONFIG options matt mooney
2011-05-11 21:09 ` Greg KH
2011-05-11 8:54 ` [PATCH 10/12] staging: usbip: stub.h: reorganize matt mooney
2011-05-11 8:54 ` [PATCH 11/12] staging: usbip: vhci.h: reorganize matt mooney
2011-05-11 8:54 ` [PATCH 12/12] staging: usbip: usbip_common.h: reorganize and document request headers matt mooney
2011-05-11 21:14 ` [PATCH 00/12] staging: usbip: miscellaneous code cleanup Greg KH
2011-05-11 23:08 ` matt mooney
2011-05-11 23:18 ` Greg KH [this message]
2011-05-12 3:24 ` matt mooney
2011-05-12 5:31 ` Greg KH
2011-05-12 5:41 ` matt mooney
2011-05-12 16:38 ` Greg KH
2011-05-12 5:08 ` [PATCH 09/12 v2] staging: usbip: edit Kconfig and rename CONFIG options mfmooney
2011-05-12 5:08 ` [PATCH 03/12 v2] staging: usbip: fix header includes mfmooney
2011-05-12 5:17 ` [PATCH 09/12 v3] staging: usbip: edit Kconfig and rename CONFIG options mfmooney
2011-05-12 5:32 ` Greg KH
2011-05-12 5:32 ` matt mooney
2011-05-12 13:34 ` [PATCH 00/12] staging: usbip: miscellaneous code cleanup Matthew Wilcox
2011-05-12 18:37 ` matt mooney
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=20110511231843.GC7362@kroah.com \
--to=greg@kroah.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mfmooney@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox