Re: 2.6 - sysfs sensor nameing inconsistency

[Andrey Borzenkov]

On Tuesday 23 September 2003 02:29, Greg KH wrote:
>
> Thanks, I've applied this and will send it off to Linus in a bit.
>

thank you.

> > it just arbitrarily (re-)names them. "min" is not hysteresis; name is
> > badly chosen.
>
> Do you have a proposed change to the current
> Documentation/i2c/sysfs-interface document?  If you can think of better
> names that make more sense, I'd be glad to change things to make it
> easier.
>

it is probably too late now to change sysfs names when some programs already 
use it. I'll check sysfs-interface, thank you for pointer.

> > > > 4. I do not have the slightest idea how ISA adapters look like in
> > > > sysfs and where they are located. Anyone can give me example?
> > >
> > > They show up on the legacy bus:
> > >
> > > $ tree /sys/class/i2c-adapter/i2c-1/
> > > /sys/class/i2c-adapter/i2c-1/
> > >
> > > |-- device -> ../../../devices/legacy/i2c-1
> >
> > This does not help much. Libsensors expects as adapter identification
> > either "i2c-N" or "isa". If I set it to "isa" I do not have any way to
> > determine sysfs path except by rescanning /sys/class/i2c-adapter every
> > time. Having /sys/class/i2-adapter/isa/... would be better, apparently it
> > is assumed that only one such adapter can exist.
>
> No, we internally do not differentiate between isa and non-isa adapters,
> so why should we force that on the user?  They work the same as far as
> users notice, and now we are consistant in our naming.
>

Well, I just tried to match what users get out of libsensors on 2.4. The 
reason was compatibility with /etc/sensors.conf where "isa" can possibly be 
used as part of chip name. But I'd like that someone from sensors developers 
comment on this.

thank you for your comments.

-andrey

-
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/