[PATCH] [0/12] SYSFS: Sysfs attribute improvements

[Andi Kleen]

sysdev_class attributes and class attributes do not pass
their own attribute to the low level store/show functions. This means
that itiss not possible to use shared functions for common data,
but each data item had to have its own function. Typically this
lead to ugly and big custom macro cascades in drivers, generating
the store/show functions for each attribute. This leads to 
large code and is ugly.

When the attributes are passed to the callbacks -- like they are for plain
attributes and sysdev attributes -- it's possible to "derive"
own attribute objects that carry some data, use that data and then call into 
shared store/show code.

This patchkit fixes up these callback interfaces to allow to do this. This
involves two tree sweeps for sysdev_class_attributes and class_attributes,
changing them all to accept the new attribute argument.

I tried to convert all users, but was only able to compile test on x86.

All users were converted in a single patch to avoid unbisectable
sections. I didn't put all the individual driver maintainers in cc,
they probably wouldn't need to care.

Also I added some utility functions to easier deal with arrays
of attributes. A lot of users define multiple attributes and had
to open code array handling for this. Add new sysfs interfaces
to handle the arrays directly. sysdev classes now can just
directly carry their own attributes, similar to normal classes.

Then the CPU and the NODE driver in drivers/base serve as a poster
child for the new facilities and shrink their code dramatically
by using the new facilities.

In addition I added a new string attribute type derived 
from class attributes. This allows various drivers who use
class attributes to export static version strings to just
use a single macro, no custom callbacks.

I didn't convert all drivers over to the new facilities, this
can be done gradually.

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