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 FreeBSD.org
Thu Oct 18 02:24:23 PDT 2007
Quoting "M. Warner Losh" <imp at bsdimp.com> (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).
Bye,
Alexander.
--
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : 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