From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
linux-usb@vger.kernel.org, libusb-devel@lists.sourceforge.net
Subject: Re: Extending USB_CONNECTINFO ioctl
Date: Mon, 10 Jun 2019 15:31:48 -0700 [thread overview]
Message-ID: <20190610223148.GA10147@dtor-ws> (raw)
In-Reply-To: <20190604164853.GA14605@kroah.com>
On Tue, Jun 04, 2019 at 06:48:53PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Jun 04, 2019 at 09:14:51AM -0700, Dmitry Torokhov wrote:
> > Hi Alan,
> >
> > On Tue, Jun 04, 2019 at 10:17:25AM -0400, Alan Stern wrote:
> > > On Mon, 3 Jun 2019, Dmitry Torokhov wrote:
> > >
> > > > Hi Alan, Greg,
> > > >
> > > > When running software in a jailed environment where sysfs or udev is not
> > > > readily available and one can only have an FD to usbdevfs device passed
> > > > into the jail, there is a desire to allow libusb working. Alan recently
> > > > added USBDEVFS_GET_SPEED, but we are still missing bus number and list
> > > > of port numbers on the way to the root to be able to better identify the
> > > > device in question.
> > > >
> > > > What do you think about adding a new ioctl:
> > > >
> > > > struct usbdevfs_connectinfo_ex {
> > > > __u32 size; /* size of the structure from the kernel POV */
> > >
> > > This should be an input/output parameter. That is, the original value
> > > says how big the userspace structure is, and the value stored by the
> > > kernel says how much space was actually filled in. Or alternatively,
> > > have two size fields (one for input and one for output).
> >
> > The "incoming" size is encoded in the ioctl number (the 'len' argument
> > in USBDEVFS_CONNINFO_EX()), there is no reason to add it separately (or
> > make read/write).
> >
> > >
> > > > __u32 busnum;
> > > > __u32 devnum;
> > > > __u32 speed; /* USB_SPEED_* form ch9.h */
> > > > u8 num_ports; /* Number of entries in port_numbers array */
> > > > u8 port_numbers[31]; /* Current limit in USB3.0 spec is 7 */
> > > > };
> > >
> > > Yeah, 31 is overkill. Even the USB-2.0 spec limits the topology to 7
> > > tiers (including the root hub), meaning that only 6 port numbers are
> > > needed.
> >
> > If you insist I can bring it down to 7, but this structure is short
> > lived, on stack, and there should not be many of them in the kernel, so
> > if we can avoid extending a particular field in the future I think it is
> > worth it.
>
> I don't know what USB 4 has in it (and if I did, I couldn't mention it),
> but someone who can see those specs might want to take a look at them to
> just say "yeah, 31 looks like a good number" or "nope, make it a bit
> bigger please!"
OK, I believe 7 tiers should be enough, so I'll cut it down to 7 from
31.
Thanks.
--
Dmitry
prev parent reply other threads:[~2019-06-10 22:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-04 0:24 Extending USB_CONNECTINFO ioctl Dmitry Torokhov
2019-06-04 5:38 ` Greg Kroah-Hartman
2019-06-04 14:17 ` Alan Stern
2019-06-04 16:14 ` Dmitry Torokhov
2019-06-04 16:48 ` Greg Kroah-Hartman
2019-06-10 22:31 ` Dmitry Torokhov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190610223148.GA10147@dtor-ws \
--to=dmitry.torokhov@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=libusb-devel@lists.sourceforge.net \
--cc=linux-usb@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.