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 23:18:43 +0000 [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
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
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:18 UTC|newest]
Thread overview: 70+ 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 ` matt mooney
2011-05-11 8:54 ` [PATCH 01/12] staging: usbip: change debug configuration option matt mooney
2011-05-11 8:54 ` 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 ` matt mooney
2011-05-11 8:54 ` [PATCH 03/12] staging: usbip: fix header includes matt mooney
2011-05-11 8:54 ` matt mooney
2011-05-11 21:07 ` Greg KH
2011-05-11 21:07 ` Greg KH
2011-05-11 22:54 ` matt mooney
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 8:54 ` matt mooney
2011-05-11 21:06 ` [PATCH 04/12] staging: usbip: replace usbip_u{dbg,err,info} and Greg KH
2011-05-11 21:06 ` [PATCH 04/12] staging: usbip: replace usbip_u{dbg,err,info} and printk with pr_ equivalent Greg KH
2011-05-11 22:51 ` [PATCH 04/12] staging: usbip: replace usbip_u{dbg,err,info} and matt mooney
2011-05-11 22:51 ` [PATCH 04/12] staging: usbip: replace usbip_u{dbg,err,info} and printk with pr_ equivalent matt mooney
2011-05-11 23:19 ` [PATCH 04/12] staging: usbip: replace usbip_u{dbg,err,info} and Greg KH
2011-05-11 23:19 ` [PATCH 04/12] staging: usbip: replace usbip_u{dbg,err,info} and printk with pr_ equivalent 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 ` matt mooney
2011-05-11 8:54 ` [PATCH 06/12] staging: usbip: stub_main.c: code cleanup matt mooney
2011-05-11 8:54 ` matt mooney
2011-05-11 21:08 ` Greg KH
2011-05-11 21:08 ` Greg KH
2011-05-11 22:56 ` matt mooney
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 ` 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 ` matt mooney
2011-05-11 8:54 ` [PATCH 09/12] staging: usbip: edit Kconfig and rename CONFIG options matt mooney
2011-05-11 8:54 ` matt mooney
2011-05-11 21:09 ` [PATCH 09/12] staging: usbip: edit Kconfig and rename CONFIG Greg KH
2011-05-11 21:09 ` [PATCH 09/12] staging: usbip: edit Kconfig and rename CONFIG options Greg KH
2011-05-11 8:54 ` [PATCH 10/12] staging: usbip: stub.h: reorganize matt mooney
2011-05-11 8:54 ` matt mooney
2011-05-11 8:54 ` [PATCH 11/12] staging: usbip: vhci.h: reorganize matt mooney
2011-05-11 8:54 ` 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 8:54 ` matt mooney
2011-05-11 21:14 ` [PATCH 00/12] staging: usbip: miscellaneous code cleanup Greg KH
2011-05-11 21:14 ` Greg KH
2011-05-11 23:08 ` matt mooney
2011-05-11 23:08 ` matt mooney
2011-05-11 23:18 ` Greg KH [this message]
2011-05-11 23:18 ` Greg KH
2011-05-12 3:24 ` matt mooney
2011-05-12 3:24 ` matt mooney
2011-05-12 5:31 ` Greg KH
2011-05-12 5:31 ` Greg KH
2011-05-12 5:41 ` matt mooney
2011-05-12 5:41 ` matt mooney
2011-05-12 16:38 ` Greg KH
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 ` mfmooney
2011-05-12 5:08 ` [PATCH 03/12 v2] staging: usbip: fix header includes mfmooney
2011-05-12 5:08 ` mfmooney
2011-05-12 5:17 ` [PATCH 09/12 v3] staging: usbip: edit Kconfig and rename CONFIG options mfmooney
2011-05-12 5:17 ` mfmooney
2011-05-12 5:32 ` [PATCH 09/12 v3] staging: usbip: edit Kconfig and rename CONFIG Greg KH
2011-05-12 5:32 ` [PATCH 09/12 v3] staging: usbip: edit Kconfig and rename CONFIG options Greg KH
2011-05-12 5:32 ` matt mooney
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 13:34 ` Matthew Wilcox
2011-05-12 18:37 ` matt mooney
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 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.