linux-kernel - Re: [Patch V4 1/3] usb: Add Xen pvUSB protocol description

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 24 Jul 2015 11:57:47 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Juergen Gross <jgross@...e.com>
Cc:	linux-kernel@...r.kernel.org, xen-devel@...ts.xensource.com,
	konrad.wilk@...cle.com, david.vrabel@...rix.com,
	boris.ostrovsky@...cle.com, linux-usb@...r.kernel.org
Subject: Re: [Patch V4 1/3] usb: Add Xen pvUSB protocol description

On Fri, Jul 24, 2015 at 05:51:04AM +0200, Juergen Gross wrote:
> On 07/23/2015 09:08 PM, Greg KH wrote:
> >On Thu, Jul 23, 2015 at 08:46:17AM +0200, Juergen Gross wrote:
> >>On 07/23/2015 06:36 AM, Greg KH wrote:
> >>>On Thu, Jul 23, 2015 at 06:04:39AM +0200, Juergen Gross wrote:
> >>>>On 07/23/2015 01:46 AM, Greg KH wrote:
> >>>>>On Tue, Jun 23, 2015 at 08:53:23AM +0200, Juergen Gross wrote:
> >>>>>>Add the definition of pvUSB protocol used between the pvUSB frontend in
> >>>>>>a Xen domU and the pvUSB backend in a Xen driver domain (usually Dom0).
> >>>>>>
> >>>>>>This header was originally provided by Fujitsu for Xen based on Linux
> >>>>>>2.6.18.
> >>>>>>
> >>>>>>Changes are:
> >>>>>>- adapt to Linux style guide
> >>>>>>
> >>>>>>Signed-off-by: Juergen Gross <jgross@...e.com>
> >>>>>>---
> >>>>>>  include/xen/interface/io/usbif.h | 252 +++++++++++++++++++++++++++++++++++++++
> >>>>>
> >>>>>Why is this a different interface than the existing ones we have today
> >>>>>(i.e. usbip?)  Where is it documented?  Do the Xen developers /
> >>>>
> >>>>The interface definition is living in the Xen git repository for several
> >>>>years now:
> >>>>
> >>>>git://xenbits.xen.org/xen.git -> xen/include/public/io/usbif.h
> >>>
> >>>That's header file, not a document describing the api here.
> >>
> >>I suppose you want to tell me I should add something like:
> >>
> >>Documentation/DocBook/usb/API-struct-urb.html
> >
> >Somewhere that people can refer to that describes this public-facing API
> >that "must not ever be broken or changed".  If you want to put it in a
> >documentation file, or a .h file, I don't care.
> >
> >>>>It is used e.g. in SUSE's xen kernel since 2.6.18.
> >>>
> >>>I am very aware of the amount of Xen crap in SuSE's kernel, don't use
> >>>that as an excuse for me to merge it to mainline :)
> >>
> >>:-)
> >>
> >>Wasn't meant as an excuse, just a hint why the interface can't be the
> >>same as for usbip. We have to ensure compatibility with those kernels
> >
> >This shouldn't be a kernel/kernel compability issue, as the api talks
> >between Xen and the OS, not between different OSs, right?
> 
> Depends on where the backend is living. It's the backend the frontend is
> talking to.
> 
> There is a backend in SUSE's kernels up to SLE12. So compatibility is
> to be maintained to those kernels.

Note, just because a distro merged an out of tree patch, does not mean
that mainline has to accept the same api as-is :)

> Looks as if in future there will be one in qemu.

So there's only one other backend talking to this, in one distro?

> >>and possibly other operating systems (BSD?, Windows?) which already
> >>might be using pvUSB with a Dom0 based on the SUSE xen kernel.
> >
> >Are there other operating system drivers today that use this API?  Is
> >this an API in the Xen core today that we have to support?
> 
> Yes.

Yes to both?  Which other operating systems have such a driver?

> >Some more background / descriptions would be nice to have.
> 
> I guess a documentation file giving a brief explanation about the
> interfaces of Xen wouldn't be a bad idea. This could avoid discussions
> like this.

Yes it would.

> It shouldn't define each interface, but the classes of interfaces which
> are existing (between kernel and hypervisor, frontends and backends)
> and the stability requirements. Headers like the one we are discussing
> here could then refer to this document.

Why shouldn't the protocol be documented?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/