On 2012年06月15日 01:24, Alan Stern wrote:
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?
Yeah. I will do it.
But I have an another question. Greg suggested to make the usb port
to be a real device, This maybe a tough task. E.G How to deal with relation among
hub, port and children and other problems. It will take a lot of time to discuss
and investigation.
I wonder it is possible for me to finish usb port power off mechanism firstly
(I have done it for a lot of time.(T_T)) and then make port a real device?
We can keep sysfs hierarchy same.
A proposal of making port a real device. Can we divide the whole project into
two steps?
First is to create port devices under the hub device, don't change the relation
among
hub, ports and children.
Second is to deal with their relation. Move the children under port devices.
Alan Stern
--
Best Regards
Tianyu Lan
linux kernel enabling team
--
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
