Re: [PATCH 14/14] package: Makefile: add USB/IP userspace utilities

[Greg KH <greg@kroah.com>]

On Tue, May 17, 2011 at 02:59:29PM -0700, matt mooney wrote:
> On Tue, May 17, 2011 at 2:21 PM, Greg KH <greg@kroah.com> wrote:
> > On Tue, May 17, 2011 at 02:13:01PM -0700, matt mooney wrote:
> >> On Tue, May 17, 2011 at 1:23 PM, Greg KH <greg@kroah.com> wrote:
> >> > On Sat, May 14, 2011 at 03:55:20AM -0700, matt mooney wrote:
> >> >> From: matt mooney <mfm@muteddisk.com>
> >> >>
> >> >> Add usbip-src-pkg target to generate a tarball of the userspace source.
> >> >>
> >> >> Signed-off-by: matt mooney <mfm@muteddisk.com>
> >> >> ---
> >> >>  scripts/package/Makefile |   15 ++++++++++++++-
> >> >
> >> > Is this really needed at this point in time?  I'd prefer to wait on it
> >> > before we get this code cleaned up a bit better if you don't mind.
> >>
> >> Oh yeah, of course. I only added it because I thought you wanted me to
> >> add it now.
> >
> > For some reason I thought it would be more, but there really isn't a way
> > to build the userspace code from the main root of the kernel tree is
> > there?
> 
> I do not believe there is. Since `make ...' starts the Kbuild system,
> Kbuild would have to support this otherwise we would have to
> circumvent the build system. And the closest thing to some kind of
> support I could find was in scripts/Makefile.host, but it says it is
> for binaries used during the kernel compilation process. I think this
> set of userspace utilities is further complicated by its use of
> autotools.
> 
> My use of "circumvent the build system" may be a bit harsh. I don't
> think there is anything wrong with running a parameterized instance of
> make within a target, but the short answer would be that this problem
> does not seem to have been generalized in Kbuild yet.

Ok, that's fine, I originally thought that tools like perf were somehow
hooked up to the main Makefile, when it seems they really aren't.  So
your other patches are fine, and are now applied.

We can wait on the tarball extract when the code moves into the "real"
part of the kernel.

thanks,

greg k-h