[v3] usbip: new package

Signed-off-by: Marcin Bis <marcin@bis.org.pl>
---
 package/Config.in       |    1 +
 package/usbip/Config.in |   33 +++++++++++++++++++++++++++++++++
 package/usbip/usbip.mk  |   32 ++++++++++++++++++++++++++++++++
 3 files changed, 66 insertions(+), 0 deletions(-)

Hi Marcin,

On Wed, Dec 26, 2012 at 09:55:47AM +0100, Marcin Bis wrote:
[...]
> +USBIP_VERSION = 0.1.7

This package is very old. Newer version is distributed with the kernel sources 
under drivers/staging/usbip/userspace/. I'm not sure how to extract these 
files during build. Maybe the experts here have an Idea?

baruch

> +USBIP_SITE = http://downloads.sourceforge.net/project/usbip/usbip/$(USBIP_VERSION)
> +USBIP_LICENSE = GPLv2+
> +USBIP_LICENSE_FILES = COPYING
> +USBIP_CONF_OPT = --without-tcpwrappers
> +USBIP_DEPENDENCIES = libglib2 libsysfs

baruch

> 
> This package is very old. Newer version is distributed with the
> kernel sources
> under drivers/staging/usbip/userspace/. I'm not sure how to extract
> these
> files during build. Maybe the experts here have an Idea?
> 


I would be interested too, more and more tools are distributed with the kernel that we might want to build... I'm thinking of the perf tools in particular

is there an example somewhere on how to handle these ?

Dear Jeremy Rosen,

On Wed, 26 Dec 2012 17:49:57 +0100 (CET), Jeremy Rosen wrote:

> I would be interested too, more and more tools are distributed with
> the kernel that we might want to build... I'm thinking of the perf
> tools in particular
> 
> is there an example somewhere on how to handle these ?

Unfortunately, there isn't a really good and nice way of handling these
in Buildroot for now.

I see two options:

 * Add sub-options to the "Linux kernel" package, to allow the
   installation of perf, usbip or other userspace packages whose source
   code is bundled with the kernel source code. This is the easiest
   solution, since the kernel version, sources and al. is already
   defined. But it also has major drawbacks: 1/ it makes those tools
   available only if you build your kernel with Buildroot and 2/ it
   puts the configuration options to install those tools inside the
   "Linux kernel" menu, which is not very intuitive.

 * Add separate packages for each of those tools in package/, with
   those packages depending on the "linux" package. The extract step of
   those packages could copy the source code of these tools from the
   Linux kernel source tree into their build directory, or simply build
   then directly from within the Linux kernel source tree. It solves
   drawback (2) described above, but not drawback (1).

 * Add separate packages for each of those tools in package/, and make
   them independent from the Linux package. They would for example
   download the latest stable version of the Linux kernel source code,
   and use that as a source. The extract step could be customized to
   only extract the part of the kernel sources that are actually
   relevant for this package. This would solve both drawbacks (1) and
   (2), but adds different drawbacks: it's another place where we have
   to bump the kernel version regularly, and people may want to
   configure the version of the kernel sources used to build those
   tools: the primary reason why those tools are bundled with the
   kernel sources is because the userspace-to-kernel ABI specific to
   those tools gets changed from time to time, and therefore there may
   be compatibility issues in running those tools from kernel version X
   under a system running kernel version Y.

Best regards,

Thomas

Dear Marcin Bis,

On Wed, 26 Dec 2012 09:55:47 +0100, Marcin Bis wrote:
> Signed-off-by: Marcin Bis <marcin@bis.org.pl>
> ---
>  package/Config.in       |    1 +
>  package/usbip/Config.in |   33 +++++++++++++++++++++++++++++++++
>  package/usbip/usbip.mk  |   32 ++++++++++++++++++++++++++++++++
>  3 files changed, 66 insertions(+), 0 deletions(-)

Are you still interested in getting usbip packaged in Buildroot? If so,
could you rework your patch to use instead the code bundled with the
kernel in drivers/staging/usbip/userspace, as suggested by Baruch?

The package/perf package provides an example on how to create a package
for a tool whose source code is shipped directly within the kernel
sources.

Since those comments have been made in December 2012, without further
postings from you, I'm marking the patch as "Changes requested" in
patchwork. This means that unless you post an updated version at some
point in the future, we'll no longer have 'usbip' in the list of
patches to integrate.

Thanks for your contribution!

Thomas