Winbond chips - design questions

[khali@linux-fr.org (Jean Delvare)]

> OK, new subject anyway...
> 
> What is the benefit of having all of the Winbond drivers in two files?

Benefit is obvious. It is because, hmmm... well... well you know, it's
obviously obvious ;)

> And related - what is the benefit of recycling feature tables etc.
> between all the Winbond types in lib/chips.c and prog/sensors/chips.c?

Almost as obvious as above ;)

> I can tell you the downside, for sure: I'm afraid to touch any of it
> for fear of breaking one of the other 5 chips that I *don't* have and
> *can't* test.  Sure it's free software and I don't have any
> obligation... but right now those particular bits are nigh
> unmaintainable.

I definitely agree with you on that point. Likewise, the adm1021 driver
has become a complete mess.

> I guess I'm asking for permission (and help!) in refactoring the
> Winbond drivers.  The NatSemi (lm??) drivers are closer to where I
> think we should go: two (or at most, three) related chips per file...
> and only if they are trivially different or one has a subset of
> features of the other, etc.

That's what I'd call a good objective. That's how I intend to make
things in drivers I wrote or maintain (lm83, lm90, adm1025).

> Also, what (kinds of) changes in libsensors will cause an ABI change? 
> Is it absolutely limited to the contents of lib/sensors.h?

Good question. Someone here, can't remember who, once said we would have
to change the library's version with each release. So I guess that the
ABI is likely to change that often. I don't quite understand what
exactly cause incompatibilities, nor what our numbering policy should
be. If someone is willing to explain that in details, that would be
welcome.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/