The following patch proposes a new kernel module to provide an
alternate protocol for transporting USB devices over a TCP/IP connection.
This flows from a few conversations on the Spice devel mailing list.[1][2]
I am relying heavily on the opinion of Hans de Goede, who believes
that the usbredir
It's pointless to post a patch that you know has problems with it (i.e.
it's not even in proper kernel coding style), as it will never be
reviewed or even looked at.
Thanks for the reply, and I'm sorry for the clumsy ask.
I would still appreciate feedback on two points:
1. Is the basic pre
On 07/01/2015 12:44 AM, Greg KH wrote:
> On Tue, Jun 30, 2015 at 10:34:25PM -0500, Jeremy White wrote:
>> 1. Is the basic premise reasonable? Is Hans correct in asserting that an
>> alternate USB over IP module will be considered?
>
> I have no idea, if it ful
> Assuming that's correct, then this seems to imply that the socket has raw
> plain text data being sent/received, and thus precludes the possibility
> of running any security protocol like TLS unless the kernel wants to have
> an impl of the TLS protocol.
Good point. For completeness, I'll note
On 07/02/2015 07:10 AM, Oliver Neukum wrote:
> On Thu, 2015-07-02 at 13:35 +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 02-07-15 10:45, Oliver Neukum wrote:
>>> On Wed, 2015-07-01 at 10:06 +0100, Daniel P. Berrange wrote:
>>>
I don't really think it is sensible to be defining & implementing new
On 07/02/2015 01:46 PM, Oliver Neukum wrote:
> On Thu, 2015-07-02 at 10:57 -0500, Jeremy White wrote:
>> On 07/02/2015 07:10 AM, Oliver Neukum wrote:
>>> On Thu, 2015-07-02 at 13:35 +0200, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 02-07-15 1
On 07/02/2015 02:59 PM, Alan Stern wrote:
> On Thu, 2 Jul 2015, Jeremy White wrote:
>
>>>> I don't follow that analysis. The usbip interactions with the usb stack
>>>> all seem to be atomic, and never trigger a syscall, as far as I can
>>>> tell. A
On 07/06/2015 03:20 AM, Oliver Neukum wrote:
> On Fri, 2015-07-03 at 10:51 +0200, Krzysztof Opasiak wrote:
>> Doesn't we have the same problem with functionfs/gadgetfs and
>> dummy_hcd?
>> Or with fuse?
>>
>> It's a very generic problem for all "virtualized devices" and it is
>> known for quite a
>>
>> Well, the checkpatch.pl reports were all style (and mostly whitespace);
>> roughly 3000 of them against 3000 lines of code :-/. I did review the
>> code, looking for areas where I thought it would badly cram into the
>> kernel, and I adjusted the few I found (and sent changes upstream).
>
On 07/08/2015 02:11 AM, Hans de Goede wrote:
Hi,
On 07-07-15 18:47, Jeremy White wrote:
Well, the checkpatch.pl reports were all style (and mostly whitespace);
roughly 3000 of them against 3000 lines of code :-/. I did review the
code, looking for areas where I thought it would badly cram
On 07/09/2015 05:06 AM, Alex Elsayed wrote:
Alan Stern wrote:
On Mon, 6 Jul 2015, Jeremy White wrote:
Anything else fundamental to usbip that should inform the design of a
usbredir driver? usbip appears to be based off a 2004 vintage of
dummy_hcd. I'll look thoughtfully at the cu
On 07/22/2015 09:34 AM, Greg KH wrote:
> On Wed, Jul 22, 2015 at 09:03:53AM -0500, Jeremy White wrote:
>> On 07/09/2015 05:06 AM, Alex Elsayed wrote:
>>> Alan Stern wrote:
>>>
>>>> On Mon, 6 Jul 2015, Jeremy White wrote:
>>>>
>>>>>
On 07/22/2015 12:59 PM, Sean O. Stalley wrote:
On Wed, Jul 22, 2015 at 11:55:32AM -0500, Jeremy White wrote:
I privately wrote to the Intel authors of that patch a week ago; I've
publicly included them in this thread as well. As far as I can tell,
they've been silent on this f
I've parked some working code, and I wanted to leave a pointer to it to
end this thread.
That is, the sense was that usbredir was not appropriate for the linux
kernel, because Intel was working on a driver implementing the Media
Agnostic USB standard, and having a proliferation of drivers didn't m
14 matches
Mail list logo
