public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: Mike Fedyk <mfedyk@matchmail.com>
Cc: sensors@Stimpy.netroedge.com, linux-kernel@vger.kernel.org,
	greg@kroah.com, jamagallon@able.es, PrakashKC@gmx.de,
	akpm@osdl.org
Subject: Re: 2.6.3-mm4
Date: Sun, 29 Feb 2004 11:11:39 +0100	[thread overview]
Message-ID: <20040229111139.25d69d8d.khali@linux-fr.org> (raw)
In-Reply-To: <40419A15.8030108@matchmail.com>

> Working from the premise that there is a current (old-style with
> mostly chip dependent code), libsensors has 2.4 /proc support, and
> each specific release supports one of 2.6.[0123]...

Correct, that's mostly that.

> I'm glad I'm not the maintainer of libsensors for a distribution. 
> Since you have effectively pushed the compatibility work to them. 
> Just think of angry customer complaints about this. :(

Again, this is a temporary situation. I'm struggling for a better
future, at the cost of a slightly chaotic present, admittedly.

That said, I think that most packaging systems support that kind of
dependency. Since we clearly advertise the correct combinations of
lm_sensors and Linux kernel, they should be able to handle it quite
nicely (although I admit it has to represent some work for them).

The compatibility problems brought by libsensors are not new. From the
very beginning, each new version of lm_sensors had kernel modules,
libsensors and sensors program that mostly only worked well together. It
wasn't to the point of what we are experiencing today, of course,
because things were mostly (but not always) backward compatible. Still,
supporting each and every new driver or "kind" of chip would require
upgrading to new libsensors and sensors program. This is precisely what
I want to avoid with my proposal.

> Since there is going to be an effective libsensors-new library with
> chip independent code, I suggest you put the compat code into the old
> library.

Note that there is no effective plan for such a library as of today. I
am "simply" defining an interface such that writing such a library will
be possible. I don't think I have the skills to write it at the moment,
but I have no doubt that people will do (I'm in particular thinking to
the gkrellm folks who neved liked the old library and wouldn't use it at
all, at the cost of frequent compatibility issues). That said, if nobody
seems to go on working on it within a reasonable amount of time, it's
likely that I will learn what I need to know to do it myself, since I'm
so interested in seeing it exist.

I do not plan to spend time to provide compatibility with early 2.6
kernels. First, because it would bloat the current libsensors even more.
Second, because I believe that these kernels will stop being used within
a few months or even weeks.

Distributions or individuals running 2.6 kernels these days know pretty
well that things are not fully stabilized yet. Granted, the sensors area
seems to be the more unstable realm of them all at the moment. But I
just don't think that people need to have, say, a 2.6.1 and a 2.6.3
kernel running perfectly on their system. We never had any request in
that direction so far. What they most likely want is to have a 2.4 and a
2.6 kernel working, and we do provide this compatibility.

If you really believe that we have to support all early 2.6 kernel
releases and are able to write a not-too-bloated patch for libsensors
that does this, we'll consider applying it. But it's unlikely that any
of us will want to spend time on such a patch.

Thanks.

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

  reply	other threads:[~2004-02-29 10:11 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-26  2:55 2.6.3-mm4 Andrew Morton
2004-02-26  8:22 ` 2.6.3-mm4 Alexander Hoogerhuis
2004-02-26  8:48   ` 2.6.3-mm4 Marc-Christian Petersen
2004-02-26  8:51 ` 2.6.3-mm4 Nuno Silva
2004-02-27  0:48   ` 2.6.3-mm4 Greg KH
2004-02-26 15:50 ` 2.6.3-mm4 David Martínez Moreno
2004-02-26 15:59   ` 2.6.3-mm4 Christoph Hellwig
2004-02-26 16:30 ` 2.6.3-mm4 (compile stats) John Cherry
2004-02-26 18:59   ` Mike Fedyk
2004-02-26 19:26     ` John Cherry
2004-02-26 18:50 ` 2.6.3-mm4 Matthias Hentges
2004-02-26 23:35 ` 2.6.3-mm4, sensors broken Prakash K. Cheemplavam
2004-02-27  0:03   ` Andrew Morton
2004-02-27  8:58     ` Prakash K. Cheemplavam
2004-02-27  0:11 ` 2.6.3-mm4 J.A. Magallon
2004-02-27  0:46   ` 2.6.3-mm4 Greg KH
2004-02-27  8:35     ` 2.6.3-mm4 Jean Delvare
2004-02-27 18:16       ` 2.6.3-mm4 Mike Fedyk
2004-02-27 19:59         ` 2.6.3-mm4 Jean Delvare
2004-02-29  7:51           ` 2.6.3-mm4 Mike Fedyk
2004-02-29 10:11             ` Jean Delvare [this message]
2004-02-27 16:48     ` 2.6.3-mm4 Prakash K. Cheemplavam
2004-02-27  9:00   ` 2.6.3-mm4 Prakash K. Cheemplavam
2004-02-27 23:51 ` 2.6.3-mm4 Adrian Bunk
2004-03-01  8:25 ` MM VM patches was: 2.6.3-mm4 Mike Fedyk
2004-03-01  8:44   ` Nick Piggin
2004-03-01  9:05     ` Mike Fedyk
2004-03-01  9:27       ` Nick Piggin
2004-03-01  9:47         ` Mike Fedyk
2004-03-01  9:10     ` Nick Piggin
2004-03-01  9:52       ` [PATCH] 2.6.4-rc1-mm1: vm-kswapd-incremental-min (was Re: MM VM patches was: 2.6.3-mm4) Nick Piggin
2004-03-01 10:18         ` Andrew Morton
2004-03-01 10:29           ` Nick Piggin
     [not found] <A6974D8E5F98D511BB910002A50A6647615F33F5@hdsmsx402.hd.intel.com>
2004-02-26 22:40 ` 2.6.3-mm4 Len Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040229111139.25d69d8d.khali@linux-fr.org \
    --to=khali@linux-fr.org \
    --cc=PrakashKC@gmx.de \
    --cc=akpm@osdl.org \
    --cc=greg@kroah.com \
    --cc=jamagallon@able.es \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mfedyk@matchmail.com \
    --cc=sensors@Stimpy.netroedge.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox