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 ...

Alexander Leidinger netchild at
Thu Oct 18 02:24:23 PDT 2007

Quoting "M. Warner Losh" <imp at> (from Thu, 18 Oct 2007  
01:38:27 -0600 (MDT)):

> There are people doing high precision timing applications with FreeBSD
> today.  I'm one of them.  Sensors for phase time differences are like
> pounding a screw with a hammer.  Sure, it looks like it works and
> often time it works well enough for the application.  But closer
> inspection shows the item constructed lacks structural integrity.
> There's all kinds of different nuances that need to be considered when
> doing high precision real-time timing systems.  The current time
> difference sensor interface in OpenBSD just doesn't cut it.

Warner, I already stated much earlier in the thread that I don't see a  
benefit in providing time via the sensors framework, as we already  
have a better API for this (I'm not a high precision time keeping guy,  
and I've seen the advantage of what we have even before Poul talked  
about this, as I know about the time related possibilities FreeBSD  
offers). I also said earlier that we don't have to have all OpenBSD  
sensors in FreeBSD, it depends upon the policy we use for sensors.

All of this complains about specific sensors are not a technical  
reason to object to the framework itself. If Poul would have said that  
Constantine shall make sure that there's text in sensible places that  
explain that we have a better API in FreeBSD for time and that this  
API shall be used instead of the sensors framework, than that would  
have been OK for me (I even would have supported Poul, as I clearly  
see it as a step back for us to use the sensors framework for time). I  
even asked for technical reasons, but he didn't provide them. I asked  
for them already weeks/months ago, when Poul was objecting against the  
idea of the sensors framework, but he didn't gave them. So it is not  
some days in which Poul didn't came up with technical reasons against  
the idea/framework, but weeks/months.

When he objects to some specific sensors, great! Finally a technical  
argument! After Poul repeatedly was saying for a too long time that  
the idea is that bad that he doesn't even look at the framework, I'm  
happy that he provides technical arguments now! But I have to say,  
that the technical arguments he presented so far are about small parts  
in the framework which should be polished, but nothing which makes the  
framework look like the "crap" Poul said in this thread. He came up  
with some buzzwords like ACPI and IPMI to prove his non technical  
points against the framework he presented so far, and he was  
told/shown that those work just nicely with this framework.

If it is not clear, I don't write all those mails to defend each line  
of code in the sensors framework. I write all those mails because I  
object to Pouls way of complaining without technical arguments (not  
that he presented invalid technical arguments, no, he wasn't even  
willing to present technical arguments at all in the beginning) that  
he showed for a long time in this thread. If this info is new to  
someone reading this, he should read all my mails again with this  
information again.

If someone wants to talk about technical stuff... great, I'm sure  
Constantine will discuss them with him.

If someone wants to support Poul in his raid against the _idea_ of the  
framework _without_ providing technical arguments against the _idea_,  
this person can discuss this with me until I have to go to the  
hospital next week and after I'm back a week or so later (I'm also not  
available at the weekend, sorry).


--  Alexander @ PGP ID = B0063FE7     netchild @  : PGP ID = 72077137
To say you got a vote of confidence
would be to say you needed a vote of confidence.
		-- Andrew Young

More information about the cvs-src mailing list