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

[Alexander Leidinger]

Quoting Julian Elischer <julian at elischer.org> (from Wed, 17 Oct 2007  
12:05:45 -0700):

> Sam Leffler wrote:
>> Alexander Leidinger wrote:
>>> Quoting Scott Long <scottl at samsco.org> (Mon, 15 Oct 2007 07:50:05 -0600):
>
> keep in mind htere are a lot of people out here that have no opinion
> as we haven't looked at it in detail, who may like the idea of a sensor
> framework but don't know enough about this implementation to chime in.

I keep this in mind. What I complain about is, that Poul hasn't looked  
into the implementation. He said he doesn't like the _idea_ of a  
sensors framework. He wasn't even complaining about the architecture,  
he was saying the idea is crap without technical backing. I asked him  
several times to bring specific technical points on the table, either  
an explanation what is bad about the architecture or something the  
implementation itself, but he didn't. He just repeated that the idea  
itself is crap. If he would come up with understandable technical  
arguments why something is not good, I wouldn't complain, but he  
doesn't. He's major complaint is, that he doesn't like the idea itself.

> Having spent some time in past lives supporting various sensors,
> I know that there is a crying need  for some sort of framework

Maybe you should explain this to Poul, it seems I failed to explain  
him why we would benefit from such kind of a framework.

> but that doesn't mean that it needs to be this one, or even in the kernel.

I see several levels of stuff which can be named "sensors framework" here.

One level is in the kernel. It's just an export interface to transfer  
status data from the kernel to userland. The goal of this framework is  
IMO to "collect" all this data in the kernel and provide a single  
point of contact for the userland to query this in-kernel data. That's  
what the soc project was about. Let's call this kernel sensors  
framework here.

Then there's something in the userland, what can also be named  
"sensors framework". This part would be responsible to be a single  
point of contact for to query the status data of the entire system.  
This userland part would be responsible to collect data which is  
exported from the kernel, and to collect data from userland stuff. It  
would provide an interface to be able to query the in-machine data  
(some people may say SNMP can be used for this). Let's call this  
single-system sensors framework here.

And then there's something in the network what can be named "sensors  
framework". This part would be responsible to collect sensor data in  
the entire (sub-)network and provide an interface to query the data  
from the entire (sub-)network (an example can be nagios or some  
commercial offering). Let's call this group-level sensors framework  
for now.

The term "sensor data" may by ambiguous too. When I talk about sensor  
data, this can be some data from a device, like  
temperature/voltage/humidity/tv channel/ rotation speed/pressure  
level/fill level/coordinates/whatever (what we want to include of this  
stuff or not I don't talk about, e.g., ATM I don't see a need to  
provide the TV channel via the sensors framework). Sensor data can  
also be the status of a subsystem in the kernel, some database related  
things in userland, the hitrate per second of a webserver, or  
whatever. All (more or less) of those things may in the end need to  
arrive in the group-level sensors framework. Before they arrive there,  
they ideally arrive in the single-system sensors framework (reduces  
probing complexity and the amount of work of the person who has to  
configure the group-level sensors framework). And parts of this stuff  
was in the kernel sensors framework before.

The group-level sensors framework doesn't belong into FreeBSD IMO. For  
the single-system sensors framework I have no strong opinion (and with  
bsnmp we may have some sort of this already which just needs to be a  
little bit extend (MIBs), but this depends upon your needs and  
expectations). For a kernel sensors framework it is clear, that this  
can not live it ports. To me the benefits of such a framework is  
obvious. For several other people @FreeBSD.org I have the impression,  
that it is also obvious.

I don't object if someone brings up valid technical arguments why the  
sensors framework this thread is all about is not suitable for  
FreeBSD. Look into my mails, you see I specially ask for technical  
arguments against it. But I object if someone just says it is crap  
without providing technical backing. I didn't write the code, it's not  
my baby, and if someone finds major flaws in it which can not be  
corrected, shoot it. No objections from my side. But saying that the  
idea is crap which makes it even not worth looking into this sensors  
framework, while several people think we need something like this, is  
far from being polite. And that's the reason why I object.

I don't say it's the best architecture ever. But I say it serves a lot  
of needs,  is an improvement of the current situation, and is not done  
in a very very bad way. Whoever comes up with an better way of doing  
it is welcome by me, but he should take into account that this  
specific sensors framework is shared with more than one other BSD and  
allows code sharing (I'm not talking about implementation details, I'm  
talking about the syntax/semantic). If suggested improvements  
outweight the benefits from sharing the code, great, it's welcome by  
me (and maybe the other BSDs are interested in those improvements too,  
if they are not in a way which prevents the adoption those  
improvements).

> Maybe we can find someone to arbitrate. We used to have an architecture
> board for this purpose but we got rid of it.

I think the outcome at that time was to ask core@, and they may decide  
to ask the people which formed the architecture review board before  
(or people which have a lot of knowledge in the specific area).

Bye,
Alexander.

-- 
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137
The Martian Canals were clearly the Martian's last ditch effort!