Mark M. Hoffman wrote: > Hi Hans, Rudolf: > > * Hans de Goede <j.w.r.degoede at hhs.nl> [2006-07-26 17:11:30 +0200]: >>>> I was thinking about doing things differently with regards to userspace. >>>> As I already posted to the list I'm working on a driver for the uGuru2. >>>> The driver is done (waiting for feedback from testers) but I still need >>>> todo userspace. Since the uGuru2 driver is going to be 2.6 only and >>>> since 2.6 has a clear API/ABI between userspace and the kernel for hwmon >>>> chips I was thinking about adding code to libsensors for generic 2.6 >>>> support. The idea is to write a piece of code which will come into >>>> action only if libsensors doesn't have a chip definition for a found >>>> chip and libsensors is running on a 2.6 kernel. This piece of code >>>> would then fill a dynamicly allocated structure describing the unknown >>>> chip, using the same structure as for known chips. > >> Rudolf Marek wrote: >>> Yes this is in long term plan. > > In fact, Jean Delvare & I discussed just how we would like to do this > at OLS. It is long overdue. > >> I know it has been the long term plan for a while, my suggestion is to >> write an intermediate solution for the short term (say within a couple >> of weeks) this short term solution would only kick into action for new >> chip drivers (like your k8 temp driver) leaving the behaviour unchanged >> for chips currently already supported by libsensors (although the 2.6 >> only ones may be removed after thorough testing making libsensors smaller). > > That sounds great. But, generic chip/feature discovery was not the first > thing on the plan. It turns out that libsysfs is getting yanked from a > lot of distros and so that part should be reworked first. Are you > interested in taking that on? Apparently, libsysfs was recently written > *out* of udev... we should see what they're doing instead. > > I will let Jean reproduce the rest of the plan here from his notes. > >>>> Does this sound like a plan With this in place we no longer need to >>>> write support for every new 2.6 hwmon driver, actually if this goes in I >>>> would like to see explicit support for the uGuru (1) be removed, since >>>> this generic code should do just as good of a job. >>> Yes. >>> >>> There are still questions if to rewrite the libsensors and allow LGPL or >>> change libsensors to what you propose. > > This was never really a question in my mind. I recognize that we've been > asked for a LGPL library in the past... too bad for them. I'm not going to > take on the job of rewriting *all* of libsensors just to accomodate a license > change. I think that I've brought Jean around to the same thinking. > >> I know, what I propose is not to wait for a decission but instead add >> support for unknown 2.6 driven chips to libsensors, leaving things as is >> for already supported chips. This way we no longer need to update >> libsensors each time a new 2.6 driver is added. I've been planning to >> write a patch for this evolutionary change for a while now. But first I >> would like to see some people backing the concept, I don't like writing >> code with 0%chance of getting it integrated upstream. > > I will back you. The fear of what a huge task it would be to rewrite > it has prevented us from simply maintaining it. I've been saying that > we should evolve it instead of rewriting it for some time now. I've > tried to improve the code every time I touch it... although I guess the > libsysfs stuff I did turns out to be short-lived. > Okay, I've finally had some positive feedback from my uguru2 driver testers, so I'll need to write userspace support for the uguru2 one of these days. I would prefer to sole this by writing generic 2.6 only chip support as described above. Before I start doing this, I however would first like to know wether to use libsysfs for this or not. As a Fedora developer I've asked what Fedora is planning on doing with libsysfs now udev no longer needs it. The answer was that since some other apps and libs (directfb, lm_sensors) use it it will be kept in Fedora and be maintained there. So we could keep just using OTOH Fedora also said they would drop it if no one was any longer using it, so it would not be good to be the last remaining user of libsysfs. So which way will it be? As soon as this is decided upon I can start working on generic 2.6 chip support (as time permits). Regards, Hans
