On Thu, 14 Jun 2012, Greg KH wrote:
> > > Yes, it would make it clearer when we read the code, seing dev_state *,
> > > makes me know that we know what is going on. A void * makes me know we
> > > have no clue as to what is going on :)
> >
> > Hmmm. The thing is, these values really aren't pointers -- or at
> > least, they aren't used as pointers.
>
> What are they used for then?
They are used as markers to indicate which open usbfs file "owns" a
particular port. When a user program "claims" a port, devices attached
to that port will not automatically be configured. And when the user
program does install a configuration, the interfaces will not
automatically be probed.
The idea behind this is to give virtualization programs more complete
control over the USB devices they want to export to a guest OS, without
interference from the host OS.
The cookie gets used when the usbfs file is closed. All the ports
owned by that file become un-owned once again.
It also gets used when the user program manually releases ownership of
a single port. The hub driver checks that the port really was owned
by the program's usbfs file rather than by somebody else.
For these purposes, all we need is the ability to compare two cookies
for equality. And we need to generate a separate cookie for each
distinct open file in usbfs; that's why I've been using a pointer to
usbfs's dev_state structure as the cookie.
> > What's the right type to represent an arbitrary cookie? Something
> > large enough to hold a pointer but which will never be dereferenced?
> > Unsigned long? Or maybe a typedef:
>
> If it's not going to be used as a pointer, then what is this going to be
> used as?
See above.
> > typedef void *hub_cookie_t;
> >
> > What do you suggest?
>
> struct usb_hub_cookie {
> unsigned long cookie;
> };
>
> Never use _t in new kernel code :)
I guess it will be easier to convert the void * to struct dev_state *.
Tianyu, do you want to write a separate patch to make that change, and
then update your patch to match it?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
