Date: Thu, 18 Oct 2007 08:43:19 +0200 From: Alexander Leidinger <netchild@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: Scott Long <scottl@samsco.org>, src-committers@FreeBSD.org, cvs-src@FreeBSD.org, Barros <joao.barros@gmail.com>, cvs-all@FreeBSD.org, Wilko Bulte <wb@freebie.xs4all.nl>, Sam Leffler <sam@errno.com>, Joao 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 f Message-ID: <20071018084319.7whfk1pixt8o080w@webmail.leidinger.net> In-Reply-To: <47165D09.7040909@elischer.org> References: <70e8236f0710150343k590f5be8r8cdf3fd60df4abd2@mail.gmail.com> <4713700D.8040202@samsco.org> <20071015193658.138fc9a5@deskjail> <4713A871.1080608@errno.com> <47165D09.7040909@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Julian Elischer <julian@elischer.org> (from Wed, 17 Oct 2007 =20 12:05:45 -0700): > Sam Leffler wrote: >> Alexander Leidinger wrote: >>> Quoting Scott Long <scottl@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 =20 into the implementation. He said he doesn't like the _idea_ of a =20 sensors framework. He wasn't even complaining about the architecture, =20 he was saying the idea is crap without technical backing. I asked him =20 several times to bring specific technical points on the table, either =20 an explanation what is bad about the architecture or something the =20 implementation itself, but he didn't. He just repeated that the idea =20 itself is crap. If he would come up with understandable technical =20 arguments why something is not good, I wouldn't complain, but he =20 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 =20 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 =20 status data from the kernel to userland. The goal of this framework is =20 IMO to "collect" all this data in the kernel and provide a single =20 point of contact for the userland to query this in-kernel data. That's =20 what the soc project was about. Let's call this kernel sensors =20 framework here. Then there's something in the userland, what can also be named =20 "sensors framework". This part would be responsible to be a single =20 point of contact for to query the status data of the entire system. =20 This userland part would be responsible to collect data which is =20 exported from the kernel, and to collect data from userland stuff. It =20 would provide an interface to be able to query the in-machine data =20 (some people may say SNMP can be used for this). Let's call this =20 single-system sensors framework here. And then there's something in the network what can be named "sensors =20 framework". This part would be responsible to collect sensor data in =20 the entire (sub-)network and provide an interface to query the data =20 from the entire (sub-)network (an example can be nagios or some =20 commercial offering). Let's call this group-level sensors framework =20 for now. The term "sensor data" may by ambiguous too. When I talk about sensor =20 data, this can be some data from a device, like =20 temperature/voltage/humidity/tv channel/ rotation speed/pressure =20 level/fill level/coordinates/whatever (what we want to include of this =20 stuff or not I don't talk about, e.g., ATM I don't see a need to =20 provide the TV channel via the sensors framework). Sensor data can =20 also be the status of a subsystem in the kernel, some database related =20 things in userland, the hitrate per second of a webserver, or =20 whatever. All (more or less) of those things may in the end need to =20 arrive in the group-level sensors framework. Before they arrive there, =20 they ideally arrive in the single-system sensors framework (reduces =20 probing complexity and the amount of work of the person who has to =20 configure the group-level sensors framework). And parts of this stuff =20 was in the kernel sensors framework before. The group-level sensors framework doesn't belong into FreeBSD IMO. For =20 the single-system sensors framework I have no strong opinion (and with =20 bsnmp we may have some sort of this already which just needs to be a =20 little bit extend (MIBs), but this depends upon your needs and =20 expectations). For a kernel sensors framework it is clear, that this =20 can not live it ports. To me the benefits of such a framework is =20 obvious. For several other people @FreeBSD.org I have the impression, =20 that it is also obvious. I don't object if someone brings up valid technical arguments why the =20 sensors framework this thread is all about is not suitable for =20 FreeBSD. Look into my mails, you see I specially ask for technical =20 arguments against it. But I object if someone just says it is crap =20 without providing technical backing. I didn't write the code, it's not =20 my baby, and if someone finds major flaws in it which can not be =20 corrected, shoot it. No objections from my side. But saying that the =20 idea is crap which makes it even not worth looking into this sensors =20 framework, while several people think we need something like this, is =20 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 =20 of needs, is an improvement of the current situation, and is not done =20 in a very very bad way. Whoever comes up with an better way of doing =20 it is welcome by me, but he should take into account that this =20 specific sensors framework is shared with more than one other BSD and =20 allows code sharing (I'm not talking about implementation details, I'm =20 talking about the syntax/semantic). If suggested improvements =20 outweight the benefits from sharing the code, great, it's welcome by =20 me (and maybe the other BSDs are interested in those improvements too, =20 if they are not in a way which prevents the adoption those =20 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 =20 to ask the people which formed the architecture review board before =20 (or people which have a lot of knowledge in the specific area). Bye, Alexander. --=20 http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 The Martian Canals were clearly the Martian's last ditch effort!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071018084319.7whfk1pixt8o080w>