tools: usb: usbip: adding support for older kernel versions

[Shuah Khan <shuah@kernel.org>]

On 3/18/19 12:23 PM, Brian Norris wrote:
> On Sat, Mar 16, 2019 at 4:40 PM shuah <shuah@kernel.org> wrote:
>> usbip tool is tied to the kernel version. This is reason why it is
>> co-located with the usbip driver in the kernel sources. This is not
>> a typical tool scenario to be able to use new tool on old kernels.
>>
>> I would like to understand the reasons for wanting to run new tool on
>> old kernels.
> 
> On Chromium OS, we ship more or less the same user space for a variety
> of systems, but not all of those run the same kernel. That's not
> exactly a novel concept -- many good tools are written such that they
> degrade gracefully when running with reduced feature sets (e.g., older
> kernels). While we are working on reducing the divergence and number
> of kernels we ship, it's currently a fact of life that we have to
> support multiple target kernel versions.

Thanks for the context for this change.

> 
> Is there a fundamental problem with VHCI such that it doesn't have a
> stable ABI that tools can be written against?
> 

In general the ABI is stable.

+#define V3_18_STATUS_HEADER "prt sta spd bus dev socket 
local_busid"

What's your 3.18 kernel version? I think you are missing security
fixes that prevent socket address leak in the status file.

+#define V4_4_STATUS_HEADER "prt sta spd dev      sockfd local_busid"
+#define V4_14_STATUS_HEADER "hub port sta spd dev      sockfd local_busid"

The difference here is the high speed support. Let's find a better
way to fix this than hard-coding kernel revisions in the tool.

> If stability is possible but you just don't care, then I guess we can
> fork our own version...
> 
> Or even worse, we could build N copies of usbip for N kernels. But we
> don't do that for any other user space component.
> 

It might be easier to build N versions than maintaining the fork :)

In any case, let's find ways to fix the problem with a constructive
approach.

thanks,
-- Shuah