Quoting Julian Elischer <[EMAIL PROTECTED]> (from Wed, 17 Oct 2007
12:05:45 -0700):
Sam Leffler wrote:
Alexander Leidinger wrote:
Quoting Scott Long <[EMAIL PROTECTED]> (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!
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
