On Mon, Feb 16, 2009 at 3:22 PM, Greg KH [off-list ref] wrote:

quoted

quoted

Put it on the input device, which is what is the per-device thing.  It's
much simpler than creating a new struct kobject.  You can even create a
subdirectory for your attributes if you use an attribute group (which
you should be doing anyway, it's much simpler that way.)

OK, one thing I'm not clear on: is there a clean API for adding
attributes to an existing struct device, or do I need to "subclass" it
(the C containment and delegation approach)?

device_create_file()

In the process of trying to re-factor the code for the above changes,
I ran into the problem that the show and store functions for sysfs
expect to be passed a struct device *. I can get to struct input_dev *
without problems (since struct input_dev contains the struct device,
and I can simply use container_of indirectly via to_input_dev).
However, I can't seem to get back to struct usb_xpad, because that
structure defines 2 pointers to devices, rather than simply embedding
the devices:

struct usb_xpad {
	struct input_dev *dev;		/* input device interface */
	struct usb_device *udev;	/* usb device */
...
};

This is not my code... it was set up this way in the stable xpad driver.

So it looks like I'm stuck with a struct input_dev * pointer to the
input device, a struct device * pointer in the show/store handlers,
and no way to get back to struct usb_xpad * with the container_of
macro. Unless, of course, there is something I don't know about
container_of (or another macro I can use in this instance).

Worse, I can't simply change the struct input_dev *dev to struct
input_dev dev, because the input subsystem's input_register_device
expects to have a struct input_dev * pointer allocated with
input_allocate_device, which does both a kzalloc AND initialization.
Trying to hack my driver by incorporating the initialization logic in
input_allocate_device would be stupid, since the result would be
unmaintainable. So the route out of this mess, going in the direction
of device attributes, would be to modify drivers/input/input.c to
factor the initialization away from the allocation.

So which is the lesser of two evils? Allocating a new kobject, or
mucking around with more of the input subsystem? Or am I missing
something?

Thanks,
Mike
-- 
Mike Murphy
Ph.D. Candidate and NSF Graduate Research Fellow
Clemson University School of Computing
120 McAdams Hall
Clemson, SC 29634-0974 USA
Tel: +1 864.656.2838   Fax: +1 864.656.0145
http://cirg.cs.clemson.edu/~mamurph