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
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 front since Novembe
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 front since November; I fear that they may
> have moved on, or
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:
> Anything else fundamental to usbip that should inform the design of
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:
> >>
> >>>Anything else fundamental to usbip that should inform the design of a
> >>>usbredir driver? usbip appears to be
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 current dummy
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 current dummy_hcd; please let
>> me know if ther
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 i
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 into the
kernel, and I adjusted the few I found
>>
>> 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 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 current dummy_hcd; please let
> me know if there is anything else I should
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
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 long time. This is why many tutorials about swap
>
On Fri, 3 Jul 2015, Krzysztof Opasiak wrote:
> > The point is that a device driver like usbip _cannot_ isolate the
> > running kernel from the vagaries of the network transport if part of
> > that transport occurs in userspace.
> >
> > If any part of the transport passes through userspace, you can
On 07/02/2015 10:20 PM, Alan Stern wrote:
On Thu, 2 Jul 2015, Jeremy White wrote:
Oliver is talking about the danger of having part of the communication
path for a block device run through userspace.
Imagine a situation where the client uses a USB storage device provided
by the server as a s
On Thu, 2 Jul 2015, Jeremy White wrote:
> > Oliver is talking about the danger of having part of the communication
> > path for a block device run through userspace.
> >
> > Imagine a situation where the client uses a USB storage device provided
> > by the server as a swap device. And suppose a
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 port reset will flip a few bits and return. A
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 port reset will flip a few bits and return. A urb enqueue
> >> queues and wakes a different
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 10:45, Oliver Neukum wrote:
> On Wed, 2015-07-01 at 10
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 10:45, Oliver Neukum wrote:
> >>> On Wed, 2015-07-01 at 10:06 +0100, Daniel P. Berrange 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 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 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
> >> network services which can't support strong
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
network services which can't support strong encryption and authentication.
Rather than passing the file descriptor to t
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
> network services which can't support strong encryption and authentication.
> Rather than passing the file descriptor to the kernel and having it do
> the I/O direc
Hi,
On 01-07-15 20:31, Jeremy White wrote:
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.
Go
Hi,
On 01-07-15 18:13, Greg KH wrote:
On Wed, Jul 01, 2015 at 10:55:49AM -0500, Jeremy White wrote:
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
> 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 Wed, Jul 01, 2015 at 10:55:49AM -0500, Jeremy White wrote:
> 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
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 fully replaces the usbip functionalit
On Tue, Jun 30, 2015 at 04:44:10PM -0500, Jeremy White wrote:
> This module uses the usbredir protocol and user space tools,
> which are used by the SPICE project.
>
> Signed-off-by: Jeremy White
[snip]
> diff --git a/drivers/usb/usbredir/Kconfig b/drivers/usb/usbredir/Kconfig
> new file mode 1
On Tue, Jun 30, 2015 at 10:34:25PM -0500, Jeremy White wrote:
> >
> >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 as
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 Tue, Jun 30, 2015 at 04:44:10PM -0500, Jeremy White wrote:
> This module uses the usbredir protocol and user space tools,
> which are used by the SPICE project.
>
> Signed-off-by: Jeremy White
> ---
> MAINTAINERS |6 +
> drivers/usb/Kconfig
33 matches
Mail list logo
