[lm-sensors] libsensors patches

[lm-sensors] libsensors patches

[Jean Delvare]

Hi Hans,

On Sun, 11 Mar 2007 10:17:18 -0400, Hans de Goede wrote:
> True, I've already poked one of the students who has written the dynamic 
> features support patches to get moving with regards to merging them. However 
> this was a semester project and the semester is over. So I don't know how this 
> will fare. If he doesn't get moving soon I'll jump in and start posting them 
> for review and make the necessary fixes myself.
> 
> That still leaves the question where to put these patches. I myself don't 
> really like the whole grand 3.0 scheme, because we are all really busy with 
> other stuff and IMHO don't seem to have the manpower todo a whole new release, 
> and also I don't see any improvements planned to warrant this version jump and 
> more important to break ABI compatibility. libsensors API is not ideal, if we 
> are going to break the API + ABI, then I would like to first see a redesign of 
> said API. So I would rather see small incremental steps. For example putting 
> dyn features detect in 2.10.x (or 2.12.0), but at first only for new chips, 
> then check with 2.6 only chips, and remove those one at a time from the static 
> list. An other small increment could be adding include directive support to 
> sensors.conf. An other incremenuld be to put in #ifdef's around 2.4 compat / 
> only code so that people who want to can build a version without 2.4 support.
> 
> Anyways I think I've made my preference clear. If you and Mark prefer doing a 
> 3.0 and putting new features there, then my student or I will start looking at 
> the 3.0 svn branch and adjusting the patches as needed. So let me know what it 
> will be.

I don't really care, libsensors is more or less Mark's realm, I am busy
enough with the kernel side of things. As long as we do not duplicate
the effort in two different branches, I'm fine. Also keep in mind that
the 2.10.x branch _must_ be stable. We must be able to release a new
version any time if there's a need, as is the case for 2.10.3. Going
with a 3.0.x branch makes it possible to make things unstable if it's
easier that way.

-- 
Jean Delvare

[lm-sensors] libsensors patches

[Hans de Goede]

Jean Delvare wrote:
> Hi Hans,

<stuff about me prefering small increments in 2.10 instead of doing 3.0
  snipped>

> I don't really care, libsensors is more or less Mark's realm, I am busy
> enough with the kernel side of things. As long as we do not duplicate
> the effort in two different branches, I'm fine. Also keep in mind that
> the 2.10.x branch _must_ be stable. We must be able to release a new
> version any time if there's a need, as is the case for 2.10.3. Going
> with a 3.0.x branch makes it possible to make things unstable if it's
> easier that way.

The patches I'm talking about where specificly designed to:
1) Keep backwards compatibility
2) Not change any behaviour for chips already supported. Actually for
    chips already supported the whole code path they introduce is never
    entered.

This minimizing the chance of introducing instability. Also keep in mind 
that a 3.0 branch will not be thoroughly tested by a wide audience until 
released , so that won't help much either.

Anyways lets wait and see what Mark has to say, I've made my preferences 
clear and I will follow whatever Mark decides.

Regards,

Hans

[lm-sensors] libsensors patches

[Mark M. Hoffman]

Hi Hans, Jean:

* Hans de Goede <j.w.r.degoede at hhs.nl> [2007-03-11 15:54:18 +0100]:
> 
> 
> Jean Delvare wrote:
> > Hi Hans,
> 
> <stuff about me prefering small increments in 2.10 instead of doing 3.0
>   snipped>
> 
> > I don't really care, libsensors is more or less Mark's realm, I am busy
> > enough with the kernel side of things. As long as we do not duplicate
> > the effort in two different branches, I'm fine. Also keep in mind that
> > the 2.10.x branch _must_ be stable. We must be able to release a new
> > version any time if there's a need, as is the case for 2.10.3. Going
> > with a 3.0.x branch makes it possible to make things unstable if it's
> > easier that way.
> 
> The patches I'm talking about where specificly designed to:
> 1) Keep backwards compatibility
> 2) Not change any behaviour for chips already supported. Actually for
>     chips already supported the whole code path they introduce is never
>     entered.
> 
> This minimizing the chance of introducing instability. Also keep in mind 
> that a 3.0 branch will not be thoroughly tested by a wide audience until 
> released , so that won't help much either.
> 
> Anyways lets wait and see what Mark has to say, I've made my preferences 
> clear and I will follow whatever Mark decides.

First, I should be clear: I was planning to modify the libsensors ABI for
libsensors 3.0.  That's the reason behind incrementing the major rev number
from 2 to 3.

However, I was not planning to do a complete redesign.  I just don't have the
time for that.  Here is an example of the type of change I'm planning to make:

-extern int sensors_match_chip(sensors_chip_name chip1, 
-                              sensors_chip_name chip2);
+extern int sensors_match_chip(const sensors_chip_name *chip1, 
+                              const sensors_chip_name *chip2);

That breaks the ABI, but it's not a redesign.  Nor does it make it very
difficult for libsensors users to update.  The most significant change would be
to add 'include' functionality to the config scanner.  

However, I do appreciate that a true redesign may be warranted.  If you want to
tackle this, please don't let me hold you back.  The sensors project has always
been very liberal about SVN access and contributors, because we haven't had the
luxury of having many contributors with lots of time.

If people with more time and/or energy come along, I don't want to stand in the
way just because I've been around longer.  I can also tell you that Jean feels
the same way (we're both on #linux-sensors as I write this.)

So how about this: you get SVN access, and get these patches committed to a
feature branch (as I did some time ago for the scanner).  If everything's ready
before 2.10.4, *you* can merge them back to the main line.  If it turns out you
decide to go in a different direction (destabilize the API/ABI or whatever)
then you're already on a branch so it's no big deal.

Meanwhile, I'll work on the remainder of the 3.0 material on the branch I
already have open, as I have time.  If it turns out that you want to do a
complete API/ABI redesign, I can always abandon that part of the 3.0 branch.

Does that sound OK?

Regards,

-- 
Mark M. Hoffman
mhoffman at lightlink.com

[lm-sensors] libsensors patches

[Hans de Goede]

Mark M. Hoffman wrote:
> Hi Hans, Jean:
> 

<quoted stuff snipped>

> 
> First, I should be clear: I was planning to modify the libsensors ABI for
> libsensors 3.0.  That's the reason behind incrementing the major rev number
> from 2 to 3.
> 
> However, I was not planning to do a complete redesign.  I just don't have the
> time for that.  Here is an example of the type of change I'm planning to make:
> 
> -extern int sensors_match_chip(sensors_chip_name chip1, 
> -                              sensors_chip_name chip2);
> +extern int sensors_match_chip(const sensors_chip_name *chip1, 
> +                              const sensors_chip_name *chip2);
> 
> That breaks the ABI, but it's not a redesign.  Nor does it make it very
> difficult for libsensors users to update.  The most significant change would be
> to add 'include' functionality to the config scanner.  
> 

Why? I understand this may be an improvement speed-wise, but libsensors 
is afaik not really speed critical. To me (as a packager of a distro 
maintaining over a 100 packages) this is needless ABI breakage and as a 
packager I strongly dislike that. Breaking ABI is not something that 
should be done lightly and thus is in this case not warrented IMHO.

> However, I do appreciate that a true redesign may be warranted.  If you want to
> tackle this, please don't let me hold you back.  The sensors project has always
> been very liberal about SVN access and contributors, because we haven't had the
> luxury of having many contributors with lots of time.
> 

As said the API is not all it could be, but it works, accept for adding 
something to get the type of a feature I think it will do for now.

> If people with more time and/or energy come along, I don't want to stand in the
> way just because I've been around longer.  I can also tell you that Jean feels
> the same way (we're both on #linux-sensors as I write this.)
> 
> So how about this: you get SVN access, and get these patches committed to a
> feature branch (as I did some time ago for the scanner).  If everything's ready
> before 2.10.4, *you* can merge them back to the main line.  If it turns out you
> decide to go in a different direction (destabilize the API/ABI or whatever)
> then you're already on a branch so it's no big deal.
> 

Sounds like a good plan to me. My preferred user name is jwrdegoede. Do 
you want a public ssh-key? I can pgp sign the mail with the key with a 
long registered pgp-key if you want.

> Meanwhile, I'll work on the remainder of the 3.0 material on the branch I
> already have open, as I have time.  If it turns out that you want to do a
> complete API/ABI redesign, I can always abandon that part of the 3.0 branch.
> 

As said I've no plans to redo the ABI, my point is more that as long as 
we don't redesign it I see no reason for a 3.0 .

Regards,

Hans

[lm-sensors] libsensors patches

[Mark M. Hoffman]

Hi Hans:

> Mark M. Hoffman wrote:
> > First, I should be clear: I was planning to modify the libsensors ABI for
> > libsensors 3.0.  That's the reason behind incrementing the major rev number
> > from 2 to 3.
> > 
> > However, I was not planning to do a complete redesign.  I just don't have
> > the time for that.  Here is an example of the type of change I'm planning
> > to make:
> > 
> > -extern int sensors_match_chip(sensors_chip_name chip1, 
> > -                              sensors_chip_name chip2);
> > +extern int sensors_match_chip(const sensors_chip_name *chip1, 
> > +                              const sensors_chip_name *chip2);
> > 
> > That breaks the ABI, but it's not a redesign.  Nor does it make it very
> > difficult for libsensors users to update.  The most significant change
> > would be to add 'include' functionality to the config scanner.  

* Hans de Goede <j.w.r.degoede at hhs.nl> [2007-03-11 18:13:05 +0100]:
> Why? I understand this may be an improvement speed-wise, but libsensors 
> is afaik not really speed critical. To me (as a packager of a distro 
> maintaining over a 100 packages) this is needless ABI breakage and as a 
> packager I strongly dislike that. Breaking ABI is not something that 
> should be done lightly and thus is in this case not warrented IMHO.

Speed is the concrete improvement... but it's also an aesthetic improvement.

And... is this really much different than extending the API from a packaging
standpoint?  If the program uses the new library function, then the new library
is obviously required.  Once you move forward, you can't move back.

The 'include' functionality comes into play also.  Existing libsensors will
break if they find an include line.  It seems this would warrant a new major
rev number anyway... so I thought I may as well 'fix' the other stuff.

Plus there is the issue of killing all 2.4.x kernel support.  I guess, no one
change here warrants the move to 3.0 all by itself.  But when you add them up,
I think it will be *easier* for distro people to accomodate this in one chunk
than to spread it out over the next 3 minor revisions.

> > However, I do appreciate that a true redesign may be warranted.  If you
> > want to tackle this, please don't let me hold you back.  The sensors
> > project has always been very liberal about SVN access and contributors,
> > because we haven't had the luxury of having many contributors with lots of
> > time.
> > 
> 
> As said the API is not all it could be, but it works, accept for adding
> something to get the type of a feature I think it will do for now.
> 
> > If people with more time and/or energy come along, I don't want to stand in
> > the way just because I've been around longer.  I can also tell you that
> > Jean feels the same way (we're both on #linux-sensors as I write this.)
> > 
> > So how about this: you get SVN access, and get these patches committed to a
> > feature branch (as I did some time ago for the scanner).  If everything's
> > ready before 2.10.4, *you* can merge them back to the main line.  If it
> > turns out you decide to go in a different direction (destabilize the
> > API/ABI or whatever) then you're already on a branch so it's no big deal.
> > 
> 
> Sounds like a good plan to me. My preferred user name is jwrdegoede. Do 
> you want a public ssh-key? I can pgp sign the mail with the key with a 
> long registered pgp-key if you want.

(I will reply to this in private.)

> > Meanwhile, I'll work on the remainder of the 3.0 material on the branch I
> > already have open, as I have time.  If it turns out that you want to do a
> > complete API/ABI redesign, I can always abandon that part of the 3.0 branch.
> > 
> 
> As said I've no plans to redo the ABI, my point is more that as long as 
> we don't redesign it I see no reason for a 3.0 .

I don't agree.  I think the sum of changes we are planning does warrant the
move to 3.0.  It will be easier than the alternative, e.g.:

	2.10.4 - drop support for 2.4.x proc file access
	2.10.5 - new API function
	2.10.6 - include command in config file

Regards,

-- 
Mark M. Hoffman
mhoffman at lightlink.com

[lm-sensors] libsensors patches

[Mark M. Hoffman]

Hi Hans:

* Hans de Goede <j.w.r.degoede at hhs.nl> [2007-03-11 18:13:05 +0100]:
> Sounds like a good plan to me. My preferred user name is jwrdegoede. Do 
> you want a public ssh-key? I can pgp sign the mail with the key with a 
> long registered pgp-key if you want.

I'm not expert w/ trac, but it seems all I had to do was move your existing
trac username "jwrdegoede" from one list to another, and that should do it.

So, if you do e.g. 'svn checkout --username jwrdegoede ...' it should ask you
to authenticate using the same password you already have for trac.

If that doesn't work, please let me know and I'll ask Axel Thimm for help.

Regards,

-- 
Mark M. Hoffman
mhoffman at lightlink.com

[lm-sensors] libsensors patches

[Axel Thimm]

On Sun, Mar 11, 2007 at 02:28:16PM -0400, Mark M. Hoffman wrote:
> * Hans de Goede <j.w.r.degoede at hhs.nl> [2007-03-11 18:13:05 +0100]:
> > Sounds like a good plan to me. My preferred user name is jwrdegoede. Do 
> > you want a public ssh-key? I can pgp sign the mail with the key with a 
> > long registered pgp-key if you want.

FWIW Hans already has an ssh account on the lm-sensors' machine, he
probably forgot or didn't know: It's the same as for people.atrpms.net. :)

But you only really need ssh access to lm-sensors' resources if you
want to do infrastructural work.

> I'm not expert w/ trac, but it seems all I had to do was move your existing
> trac username "jwrdegoede" from one list to another, and that should do it.

That's all there was to it.

> So, if you do e.g. 'svn checkout --username jwrdegoede ...' it should ask you
> to authenticate using the same password you already have for trac.
> 
> If that doesn't work, please let me know and I'll ask Axel Thimm for help.

If it doesn't work, PM me and Cc: Mark. If you're also interested in
the filesystem location of lm-sensors' resources on the server also
please in PM.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20070311/d1d6395d/attachment.bin 

[lm-sensors] libsensors patches

[Hans de Goede]

Mark M. Hoffman wrote:
> Hi Hans:
> 

<discussion about 3.0 versus increments snipped>

> 
> I don't agree.  I think the sum of changes we are planning does warrant the
> move to 3.0.  It will be easier than the alternative, e.g.:
> 
> 	2.10.4 - drop support for 2.4.x proc file access
> 	2.10.5 - new API function
> 	2.10.6 - include command in config file
> 

Okay, first of all this is me with my lmsensors-contributers hat firmly 
off and my packager maintaining over a 100 packages in Fedora hat firmly on:

Lets try to split 2 things here, doing a 3.0 release to indicate some 
kinda milestone and breaking the ABI.

I've got nothing against putting some big changes (esp dropping 2.4 
support) in a 3.0 release. However unless it really is necessary I'm 
against breaking the ABI.

Adding a function does not break any old applications and thus is not a 
problem, most distributions work with repositories of packages, whereby 
new packages for a repo get build against other packages already in the 
same repo. Thus before any new package in such a repo can use the new 
API functions, libsensors must be updated first. Then applications may 
start using the new function after being (re)build against the repo with 
the new libsensors in it.

Normal users use some update tool which will automaticly install all new 
packages including the new libsensors + any apps needing the new version.

Now one can do so called piecemeal upgrades manually but that is asking 
for trouble and usually voids your support if any. One of the great 
successes of gtk2 actually is that every new release is ABI compatible 
with the old, so old apps stay working.

Also keep in mind that besides package-manager installed apps a user may 
also have manually installed apps. When the package manager then updates 
a library to a new not ABI compatible (and thus hopefully a different 
soname) version, these manually installed apps will break.

In short soname changes / ABI breakage cause both user and packager pain 
and inconvenience. Thus if it isn't really necessary / there is little 
gain, as with the by const reference versus by value change you propose, 
then you should not break the ABI and thus keep the soname.

Regards,

Hans

[lm-sensors] libsensors patches

[Axel Thimm]

On Sun, Mar 11, 2007 at 08:23:25PM +0100, Hans de Goede wrote:
> Mark M. Hoffman wrote:
> > Hi Hans:
> > 
> 
> <discussion about 3.0 versus increments snipped>
> 
> > 
> > I don't agree.  I think the sum of changes we are planning does warrant the
> > move to 3.0.  It will be easier than the alternative, e.g.:
> > 
> > 	2.10.4 - drop support for 2.4.x proc file access
> > 	2.10.5 - new API function
> > 	2.10.6 - include command in config file
> > 
> 
> Okay, first of all this is me with my lmsensors-contributers hat firmly 
> off and my packager maintaining over a 100 packages in Fedora hat firmly on:
> 
> Lets try to split 2 things here, doing a 3.0 release to indicate some 
> kinda milestone and breaking the ABI.

If /proc support gets dropped then it already breaks the ABI, since
the ABI is not only about talking to the shared lib, but also to other
interfaces as well.

If you still keep half the ABI in place by not touching API and soname
of the lib, dependent projects will not notice the loss of /proc
support until runtime.

So it looks like breaking the ABI "on purpose" might be just OK. The
question is whether libsensors.so.3 and libsensors.so.4 would
peacefully coexist on a non-packaging level to allow for a smooth
transition.

On a packaging level one or both could be packaged into a subpackage
libsensors<major> to allow co-existance. Works well under both rpm and
deb worlds.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20070311/911a7899/attachment.bin 

[lm-sensors] libsensors patches

[Hans de Goede]

Axel Thimm wrote:
> On Sun, Mar 11, 2007 at 08:23:25PM +0100, Hans de Goede wrote:
>> Mark M. Hoffman wrote:
>>> Hi Hans:
>>>
>> <discussion about 3.0 versus increments snipped>
>>
>>> I don't agree.  I think the sum of changes we are planning does warrant the
>>> move to 3.0.  It will be easier than the alternative, e.g.:
>>>
>>> 	2.10.4 - drop support for 2.4.x proc file access
>>> 	2.10.5 - new API function
>>> 	2.10.6 - include command in config file
>>>
>> Okay, first of all this is me with my lmsensors-contributers hat firmly 
>> off and my packager maintaining over a 100 packages in Fedora hat firmly on:
>>
>> Lets try to split 2 things here, doing a 3.0 release to indicate some 
>> kinda milestone and breaking the ABI.
> 
> If /proc support gets dropped then it already breaks the ABI, since
> the ABI is not only about talking to the shared lib, but also to other
> interfaces as well.
> 
> If you still keep half the ABI in place by not touching API and soname
> of the lib, dependent projects will not notice the loss of /proc
> support until runtime.
> 

Agreed, thinking about this some more I'm not so sure that dropping 2.4 
support is a good idea as there is still plenty of 2.4 usage out there. 
An alternative would be to maintain both a 2.10 branch for 2.4 + 2.6 
users and a 3.0 branch for those who only use 2.6, but is the gain of a 
somewhat smaller, cleaner 3.0 branch worth the pain of maintaining 2 
branches. Also in this scenario I think we should keep them atleast API 
compatible from the application pov, as some distros may want to ship 
2.10 then while others ship 3.0. This is exactly why I've suggested to 
turn 2.4 support into an ifdef instead of ripping it out.

> So it looks like breaking the ABI "on purpose" might be just OK. The
> question is whether libsensors.so.3 and libsensors.so.4 would
> peacefully coexist on a non-packaging level to allow for a smooth
> transition.
> 

IOW, no sensors.conf format changes for example?

Regards,

Hans

[lm-sensors] libsensors patches

[Axel Thimm]

On Sun, Mar 11, 2007 at 08:53:43PM +0100, Hans de Goede wrote:
> Agreed, thinking about this some more I'm not so sure that dropping 2.4 
> support is a good idea as there is still plenty of 2.4 usage out there. 

I would second keeping 2.4 support if it's not too much pain. Many
RHEL3 users pick i2c/lm_sensors' kernel modules at ATrpms for
supporting their hardware.

But if 2.4 support is slowing down things and developer resources want
to concentrate on 2.6 it will have to go sooner or later.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20070311/6ee2ec35/attachment.bin 

[lm-sensors] libsensors patches

[Mark M. Hoffman]

Hi Hans, Axel:

* Hans de Goede <j.w.r.degoede at hhs.nl> [2007-03-11 20:53:43 +0100]:
> 
> 
> Axel Thimm wrote:
> > On Sun, Mar 11, 2007 at 08:23:25PM +0100, Hans de Goede wrote:
> >> Mark M. Hoffman wrote:
> >>> Hi Hans:
> >>>
> >> <discussion about 3.0 versus increments snipped>
> >>
> >>> I don't agree.  I think the sum of changes we are planning does warrant the
> >>> move to 3.0.  It will be easier than the alternative, e.g.:
> >>>
> >>> 	2.10.4 - drop support for 2.4.x proc file access
> >>> 	2.10.5 - new API function
> >>> 	2.10.6 - include command in config file
> >>>
> >> Okay, first of all this is me with my lmsensors-contributers hat firmly 
> >> off and my packager maintaining over a 100 packages in Fedora hat firmly on:
> >>
> >> Lets try to split 2 things here, doing a 3.0 release to indicate some 
> >> kinda milestone and breaking the ABI.
> > 
> > If /proc support gets dropped then it already breaks the ABI, since
> > the ABI is not only about talking to the shared lib, but also to other
> > interfaces as well.
> > 
> > If you still keep half the ABI in place by not touching API and soname
> > of the lib, dependent projects will not notice the loss of /proc
> > support until runtime.
> > 
> 
> Agreed, thinking about this some more I'm not so sure that dropping 2.4 
> support is a good idea as there is still plenty of 2.4 usage out there. 
> An alternative would be to maintain both a 2.10 branch for 2.4 + 2.6 
> users and a 3.0 branch for those who only use 2.6, but is the gain of a 
> somewhat smaller, cleaner 3.0 branch worth the pain of maintaining 2 

This was my intention all along, except, with the idea that 2.10.4 or .5 would
be the last of that line.  We barely have time to keep up with the 2.6 kernel;
IMHO we should have dropped 2.4 kernel support a year or two ago.

And if we're going to put sensors 2.10.x in a deep freeze, then I don't want
to have to make bugfixes in two places, like you say.  Thus, I wanted all of
these new features to wait for 3.0.

> branches. Also in this scenario I think we should keep them atleast API 
> compatible from the application pov, as some distros may want to ship 
> 2.10 then while others ship 3.0. This is exactly why I've suggested to 
> turn 2.4 support into an ifdef instead of ripping it out.

Non-sequitor?  I don't understand why distros *couldn't* choose as you say,
or just ship both.  OK, so a kernel 2.4 distro can't ship sensors 3.0.  But
that's just too bad.  They can't ship the most recent udev or modprobe either.

> > So it looks like breaking the ABI "on purpose" might be just OK. The
> > question is whether libsensors.so.3 and libsensors.so.4 would
> > peacefully coexist on a non-packaging level to allow for a smooth
> > transition.
> > 
> 
> IOW, no sensors.conf format changes for example?

Right, the config file change is the biggest problem here... *if* the new
functionality is actually used.  If no 'include' command appears in a config
file, then it will work for both major versions.  The intended use case for
the include feature is probably a long way off anyway.

I don't forsee any other problems.

Regards,

-- 
Mark M. Hoffman
mhoffman at lightlink.com

[lm-sensors] libsensors patches

[Hans de Goede]

Mark M. Hoffman wrote:
> Hi Hans, Axel:
> 
> And if we're going to put sensors 2.10.x in a deep freeze, then I don't want
> to have to make bugfixes in two places, like you say.  Thus, I wanted all of
> these new features to wait for 3.0.
> 

Now I understand your motivations better!, Thanks.

>> branches. Also in this scenario I think we should keep them atleast API 
>> compatible from the application pov, as some distros may want to ship 
>> 2.10 then while others ship 3.0. This is exactly why I've suggested to 
>> turn 2.4 support into an ifdef instead of ripping it out.
> 
> Non-sequitor?  I don't understand why distros *couldn't* choose as you say,
> or just ship both.  OK, so a kernel 2.4 distro can't ship sensors 3.0.  But
> that's just too bad.  They can't ship the most recent udev or modprobe either.
> 

Notice that I said application API this time not application ABI, if we 
are going to say that 2.10 will stay around in some form for kernel 2.4 
+ 2.6 users and that 3.0 is all shiny and new for 2.6 only users, then 
we need them to be API compatible if possible because:
-We don't want application programmers to have to put their code full
  of: #ifdef LM_SENSORS3 ... #else ... #endif
-Now assuming 3.0 becomes an instant smash hit then most appplications
  might just move over, thus requiring 3.0 to compile and run ->
  problem 2.4 kernel / 2.10 libsensors users are left in the cold / with
  older versions of these applications

Thus as I keep re-iterating breaking (not extending but breaking) the 
API for the single goal of moving from pass by value to pass by const 
reference one way or the other causes users pain and IMHO more pain then 
gain.

Regards,

Hans

[lm-sensors] libsensors patches

[Jean Delvare]

On Sun, 11 Mar 2007 13:44:19 -0400, Mark M. Hoffman wrote:
> * Hans de Goede <j.w.r.degoede at hhs.nl> [2007-03-11 18:13:05 +0100]:
> > Why? I understand this may be an improvement speed-wise, but libsensors 
> > is afaik not really speed critical. To me (as a packager of a distro 
> > maintaining over a 100 packages) this is needless ABI breakage and as a 
> > packager I strongly dislike that. Breaking ABI is not something that 
> > should be done lightly and thus is in this case not warrented IMHO.
> 
> Speed is the concrete improvement... but it's also an aesthetic improvement.
> 
> And... is this really much different than extending the API from a packaging
> standpoint?  If the program uses the new library function, then the new library
> is obviously required.  Once you move forward, you can't move back.
> 
> The 'include' functionality comes into play also.  Existing libsensors will
> break if they find an include line.  It seems this would warrant a new major
> rev number anyway... so I thought I may as well 'fix' the other stuff.
> 
> Plus there is the issue of killing all 2.4.x kernel support.  I guess, no one
> change here warrants the move to 3.0 all by itself.  But when you add them up,
> I think it will be *easier* for distro people to accomodate this in one chunk
> than to spread it out over the next 3 minor revisions.

I wholeheartedly agree with this statement.

-- 
Jean Delvare

[lm-sensors] libsensors patches

[Jean Delvare]

Hi Axel, Hans, all,

On Sun, 11 Mar 2007 21:28:46 +0100, Axel Thimm wrote:
> On Sun, Mar 11, 2007 at 08:53:43PM +0100, Hans de Goede wrote:
> > Agreed, thinking about this some more I'm not so sure that dropping 2.4 
> > support is a good idea as there is still plenty of 2.4 usage out there. 
> 
> I would second keeping 2.4 support if it's not too much pain. Many
> RHEL3 users pick i2c/lm_sensors' kernel modules at ATrpms for
> supporting their hardware.

Come on, I'm tired of all this whining each time we say that we want to
drop 2.4 support. Users need to get a life and finally understand that
you can't run a 3-year old kernel on brand new hardware and expect
everything to work. If they want to be stupid and do that, great, but
then they are on their own and they better don't come and ask me to
support them.

The drop of 2.4 support is a fact already. We are no longer writing new
drivers for 2.4, and when 2.4 drivers are backported by others
(w83627ehf, smsc47m192) we don't have the time to review them anyway.
All the new hardware we added support for in 2.6 lately (?Guru, K8
integrated sensors, ADM1029, IT8716F, IT8718F, PC87427, W83793) isn't
supported with 2.4 kernels.

The only new hardware support will still backport is when it's as easy
as adding a new device ID in an old driver. And I think I'm nice enough
to do that - Mark suggested to plain _kill_ 2.4 support one year ago
already.

> But if 2.4 support is slowing down things and developer resources want
> to concentrate on 2.6 it will have to go sooner or later.

That's the case exactly. We hardly have time to keep up with the new
drivers for 2.6 and all the infrastrcuture changes that are long
overdue.

If people are interested in continued 2.4 kernel support, that's
alright, but then they get to do the job themselves. They stop whining,
they join the project, and they do the job themselves.

It might be worth remining everyone that Rudolf, Mark and myself, to
name only the three most active contributors, are working on lm-sensors
on our spare time, for free, because we think it's fun. We don't owe
anything to anyone out there. Free software doesn't mean developers are
the users' slaves and do everything for free on request. Free software
means that whoever wants something gets to do the job.

-- 
Jean Delvare

[lm-sensors] libsensors patches

[Axel Thimm]

On Mon, Mar 12, 2007 at 11:12:36AM +0100, Jean Delvare wrote:
> Hi Axel, Hans, all,
> 
> On Sun, 11 Mar 2007 21:28:46 +0100, Axel Thimm wrote:
> > On Sun, Mar 11, 2007 at 08:53:43PM +0100, Hans de Goede wrote:
> > > Agreed, thinking about this some more I'm not so sure that dropping 2.4 
> > > support is a good idea as there is still plenty of 2.4 usage out there. 
> > 
> > I would second keeping 2.4 support if it's not too much pain.

> Come on, I'm tired of all this whining each time we say that we want
> to drop 2.4 support.  [...] The drop of 2.4 support is a fact
> already. We are no longer writing new drivers for 2.4, and when 2.4
> drivers are backported by others (w83627ehf, smsc47m192) we don't
> have the time to review them anyway.

> > But if 2.4 support is slowing down things and developer resources
> > want to concentrate on 2.6 it will have to go sooner or later.
> 
> That's the case exactly. We hardly have time to keep up with the new
> drivers for 2.6 and all the infrastrcuture changes that are long
> overdue.

I'm instantly redrawing my just-nice-to-have-if-its-no-pain request. :)

Many thanks for keeping this project up and fresh! I agree that if
RHEL3 consumers are interested then they should be able to throw in
resources. But that's not going to happen.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20070312/fdbf2e30/attachment.bin