On 8/3/05, Jim Cromie <jcromie at divsol.com> wrote:
> IIUC, the 'much better' is passing a *dev-attr,
> doing to_sensor_dev_attr() on it to get the full SDA
> in a typesafe manner, then using whatever new members
> you have added (ex index, and for sda2, nr also)
>
> or have I missed something ?
Well the change affects more than sensors of course, and there is a
lot of code other places in the kernel with the same problem (and not
just for device_attribute), so I expect to see other structs out there
like sensor_device_attribute, but yes basically :-). Its much less
error prone than a void * as you say because of it's typesafe manner,
and doesn't require us to add anything to the sysfs attribute struct
itself.
> just to follow up, rc4-mm1 has
>
> struct sensor_device_attribute{
> struct device_attribute dev_attr;
> int index;
> };
> struct sensor_device_attribute_2 {
> struct device_attribute dev_attr;
> u8 index;
> u8 nr;
> };
I never noticed that, looks like it originated in this patch:
http://lists.lm-sensors.org/pipermail/lm-sensors/2005-July/013104.html.
Is sensor_device_attribute_2 useful to enough drivers (>1) to justify
putting it in hwmon-sysfs? Otherwise maybe its better off just being
defined by that driver itself...
> Ive used the 1st sda in my latest patch-set, are these structs 'stable' ?
Is anything stable in the kernel? I don't expect it to disappear
anytime soon though.
> .index is still there, with more room than is useful for file-entries in
> a sysfs dir-node.
> Any reason not to shorten the index, to 'reserve' another short ?
Hmm..that's an interesting proposition, what is the limit for the
number of sysfs attributes in a directory? It certainly doesn't make
any sense to use an int if a short will suffice for even the maximum.
Yani
