Date: Sun, 14 Oct 2007 11:16:48 -0700 From: Sam Leffler <sam@errno.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Alexander Leidinger <netchild@FreeBSD.org>, cvs-all@FreeBSD.org Subject: Re: 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 files ... Message-ID: <47125D10.4080704@errno.com> In-Reply-To: <66400.1192378445@critter.freebsd.dk> References: <66400.1192378445@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote:
> In message <200710141045.l9EAjW4m058732@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).
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47125D10.4080704>