cvs commit: src/etc Makefile sensorsd.conf src/etc/defaults rc.conf src/etc/rc.d Makefile sensorsd src/lib/libc/gen sysctl.3 src/sbin/sysctl sysctl.8 sysctl.c src/share/man/man5 rc.conf.5 src/share/man/man9 Makefile sensor_attach.9 src/sys/conf f

[Constantine A. Murenin]

On 14/10/2007, Sam Leffler <sam at errno.com> wrote:
> Poul-Henning Kamp wrote:
> > In message <200710141045.l9EAjW4m058732 at repoman.freebsd.org>, Alexander Leiding
> > er writes:
> >
> >
> >>  Log:
> >>  Import OpenBSD's sysctl hardware sensors framework.
> >>
> >
> > I would like to register a complaint about this commit.
> >
> > When this was discussed I objected that this entire pile of crap does
> > not belong in the kernel.
> >
> > I still think this is a festering junkpile that does not belong in
> > the kernel, and that his should be backed out, until a proper
> > architectural solution has been found.
> >
> > Adding a new bogus type of device tree just because on cannot be
> > bothered to do things right, is the road that leads to things like
> > SYSV IPC and away from a sustainable architecture for an operating
> > system which is here for the long term.
> >
> > Please back this out.
> >
>
> I'd have to agree that these changes need more buy in and review.  I
> recall many folks voiced complaints when the work was submitted to p4.
> There are basic design issues that need to be resolved such as whether
> code that's been added to the kernel is needed (instead of doing
> user-space drivers).  Having kernel support is usually dependent on
> whether it's infeasible to do the work in user space and/or using the
> results within the kernel.  I also took a quick glance at the 2 drivers
> that were added and see multiple issues that indicate this code needs
> more review (possible div-by-zero, lack of newbus integration, probing
> i2c devices, etc).

Dear Sam,

I'd be happy to hear about the possible div-by-zero bugs in any of
these drivers. If there are any such bugs, people in OpenBSD/NetBSD
and DragonFly BSD would be happy to fix 'em, as all of these systems
share the same code.

Probing i2c devices is another topic entirely. It was never even
slightly advertised to be part of this SoC project, and I'd be more
than happy to see someone to work in that area. In fact, until this
backout, I was planning to explore that area myself.

Cheers,
Constantine.

> I was very happy to see this SoC project happen and I think users could
> benefit from a common sensor framework but I'd like to see one that is a
> better fit to freebsd.
>
>     Sam