Date: Mon, 15 Oct 2007 19:52:07 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Alexander Leidinger <netchild@FreeBSD.org> Cc: Wilko Bulte <wb@freebie.xs4all.nl>, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, cvs-src@FreeBSD.org 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 files ... Message-ID: <1947.1192477927@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 15 Oct 2007 21:09:09 %2B0200." <20071015210909.1b6b693b@deskjail>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20071015210909.1b6b693b@deskjail>, Alexander Leidinger writes: >Quoting "Poul-Henning Kamp" <phk@phk.freebsd.dk> (Mon, 15 Oct 2007 15:01:47 +0000): >> >And I responded that we need to have a way to export data from the >> >kernel to userland in an unified way. >> >> I can't seem to find the supposed requirement for unification here, > >You didn't comment on what I wrote about reducing the work of >reinventing a way to export the data we want to export again and again >and again and again... Yes, that is the abstract argument, but the very same argument can be made for every other single kind of entity which consumes or produces bytes, from fingerprint readers to 9-track tape stations. My beef with this code is that it unifies a lot of non-alike measurements and indications in a new, and pretty bogus IMO, api, but adding no value above a plain old sysctl while doing so. >> and in fact, it is exactly that a lot of crap gets bundled up >> under the wildcard term of "sensor" that I object to. > >Exporting temperature readings / voltage measurement, system status is >not crap. Actually it is, if it can be done as well (or better) from userland by exporting the underlying communications paths. >And when you write some monitoring probes in a large server >farm, you don't want to hunt down every interesting data value in a lot >of places. Ahh, so this brings me to the next problem with sensors. If by "monitoring" you mean "plot MRTG graphs", then I guess sensors could possibly make sense, although, I'd have to point out that all that can be done just as well from ports/sysutils/whatever. But if you're talking real world monitoring, then sensors are pointless, because there is no way to derive necessary machine readable contextual information, such as alarm limits, resolution, calibration constants, hysteresis, polling periods etc. Or, for that matter, machine-readable information about what is actually being measured and where it is being measured and what it means. There are frameworks for doing that sort of stuff in professional server hardware, but since OpenBSD doesn't support those, IPMI, ACPI etc, they have come up with this VAX-mentality junkheap instead. >> >I already told you last time >> >that the current way (access to the i2c or smbus) needs more access >> >rights than using the userland parts of the sensors framework. >> >> More rights than what exactly ? > >One popular userland temperature/voltage reading tool (as it supports a >lot of popular devices) is mbmon. It is currently a SUID root >application. Let me get this straight, you're telling me: "I'm worried about this code running as root, so I'm putting it in the kernel instead." Can anybody here spot the logic flaw of this argument ? Anybody ? Right, I thought so. Lets pretend you didn't say that. >> No, I have yet to see why we need this framework. > >Several committers which voted for this project in the soc webinterface >seem to think otherwise, else they wouldn't have voted for it. I repeat: The SoC interface is not the gateway to -current. >> >> C) How it integrates into FreeBSD and for the places where >> >> it does not (newbus ?) why it doesn't. >> > > >We're discussing it right now. And I was willing to discuss this even >back when you talked about it the first time. It should have been dicussed and fixed before being committed to -current. Current is not where you start, it is where you end, these kind of things are not details to be hashed out in CVS. Ten years ago when we didn't have P4 and the _extensive_ infrastructure for making it easy for people to work out of the tree, we had to do stuff like that, but there is no excuse for it today. >> >The code we have currently doesn't harm the system, [...] >> >> This is where I disagree: it does harm the system. >> >> It dumps a load of badly thought out code into our source tree, and >> that will effectively be in the way of any well thought out solution >> that might ever appear. >> >> This stuff should be backed out, and forced to live outside the tree >> until it satisfies our quality and architectural requirements. > >How does this compare to your attitude of bringing stuff into the tree >and letting other people fixup collateral damage in the past? But I >drift away from the topic... so back to the sensors framework. It does not compare, please answer the question instead of trying to insult me, because you're no good at it. I have been insulted by people who were far better insulters than you, and you didn't even tickle my funny bone. (If you want to enter into a discussion of the changes in our development methodologies over the last 15 years, and the difference between peripheral optional bits and pieces, versus heavy-duty-your-system-wont- boot-without-it infrastructure, and why some code succeeds and some fails, I'll be happy to take that discussion. It's a very interesting topic to which I have devoted considerable amounts of time, but we should discuss that in a different thread, not this one.) >To be able to address our quality and architectural requirements, we >need first to know which quality and architectural requirements are >violated by which part of the code in question. As you seem to have >identified them, would you please so kind and share your concrete >findings? Would you be so kind as to read the emails I've sent you ? Maybe this time expending some effort to understand what people tell you in them, rather than pretending they contained nothing ? >> Forcing it to stay out of -current, means that the motivational >> pressure is on the people who thing we badly need this featureset, >> and gives them reason to improve it. >> >> Leaving it in the tree, is the sure fire way for it to become an >> unmaintained lump of code that slowly rots away. > >You did a psycho-analysis of Constantine so that you are able to tell >that he doesn't fix the issues while he agreed to improve the framework? No, it's far worse. I have 15 years of experience with this kind of code being slammed into the tree in an unfinished and badly thought out shape. And I have wasted far more time cleaning it up afterwards, than you or constantine will have spent on FreeBSD five years from now. I suspect I still hoover somewhere near the top of the cvs/sys commitstats that peter used to maintain, I didn't get there by accident, and I'll be damned if I let people force me or anybody else to suffer through that amount of cleanups again. >> >You object to the current implementation because you think it is bad. >> >> s/think/know/ > >Great, so you know specific issues and can tell us about them (again, >other people pointed out specific stuff already and also pointed to >things which help to let Constantine improve the issues which where >pointed out). The implementation is bad because the fundamental idea is bad. It cannot be helped IMO. >> The solution to that is to remove it from -current, let it live in >> P4 until such time that it passes muster in a review on arch@ which >> gives relevant people a chance to study and comment on it. >> >> >You don't go to court and tell someone is guilty and then the person >> >has to prove he/she is not guilty. >> >> No, I go to court, get a prelimnary injunction so that he is forced >> to stop while a proper review is carried out. > >And the judge first listens to your arguments and makes up his mind >before he issues a preliminary injunction. I seem to recall that quite a number of people have objected and several very senior developers have said "back out" already now. Your resistance to subtle clues would make you an execellent candidate for the US presidency, but it makes you a very poor FreeBSD committer. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1947.1192477927>