'Re: Sysctl as a Service, or: making sysctl(3) more friendly for monitoring systems'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: Sysctl as a Service, or: making sysctl(3) more friendly for monitoring systems
From:       "Constantine A. Murenin" <cnst++ () freebsd ! org>
Date:       2016-12-14 23:39:24
Message-ID: CAPKkNb7=De_QVpDk_-VPGhwre3jU6w2V5n+ED9+iUec=ooX4Qg () mail ! gmail ! com
[Download RAW message or body]

On 14 December 2016 at 07:20, Alexander Leidinger
<Alexander@leidinger.net> wrote:
> Quoting Adrian Chadd <adrian.chadd@gmail.com> (from Mon, 12 Dec 2016
> 23:32:00 -0800):
> 
> > On 12 December 2016 at 22:03, Warner Losh <imp@bsdimp.com> wrote:
> > > 
> > > On Mon, Dec 12, 2016 at 10:49 PM, Adrian Chadd <adrian.chadd@gmail.com>
> > > wrote:
> > > > 
> > > > If only we had a mechanism for these kinds of sensors to register, so
> > > > the API they'd be using would be one that lead itself to edge/level
> > > > triggered comparisons, versus polling.
> > > > 
> > > > Wait, didn't we /have/ one of those up for review a few years ago, and
> > > > it wasn't merged in?
> > > 
> > > 
> > > Didn't we have people willing to work with the folks that put this up
> > > when to address the defects in the review? Oh, wait, they never wanted
> > > to work to fix the problems, even with many offers of help to do so.

Most of the discussion was heavily politicised.

It was a long time ago; however, I do not recall anyone making any
concrete offers of what exactly had to be fixed.  I think it would
only be fair to say that someone didn't want "to work to fix the
problems" if by that you mean that after so much backlash/politics,
someone wasn't motivated enough to start an entirely new project,
entirely from scratch, on their own spare time, even though an
existing one did the job already.  In fact, this wasn't just my own
conclusion, many others have arrived at the same conclusion as well.

That is not to say that the framework is without issues, however.
I've documented my view on the subject within my MMath CS thesis, you
can jump directly to Section 8, "Port to FreeBSD / DragonFly BSD":

    http://uwspace.uwaterloo.ca/handle/10012/5234
    http://uwspace.uwaterloo.ca/bitstream/handle/10012/5234/UW.MMath.CS.murenin.cnst-sensors.2010-05-21.pages09.pdf

> > > 
> > > My offer still stands, btw.

As it's been almost ten years, perhaps you are thinking of another,
more recent discussion instead:

    http://lists.freebsd.org/pipermail/freebsd-acpi/2010-April/006452.html

Your comments and guidance in that thread was very specific, helpful
and valued, got immediately addressed to everyone's mutual
satisfaction, and the results were successfully committed without any
controversy, 6 years and counting — the *BSD aibs(4) driver in
question is still present in FreeBSD, as well as all the other BSDs,
too:

    http://mdoc.su/f/aibs.4
    http://mdoc.su/f110,n70,d,o60/aibs.4

If there are any concrete dealbreaker issues that could likewise be
addressed w/r/t the sensors framework, I'd be happy to hear them.

> > 
> > 
> > Heh, this wasn't a troll? :) I should've been clearer!
> > 
> > Does anyone remember where the ye olde framework was?
> 
> 
> Original:
> - Google Summer of Code 2007.
> - I don't find the repo in svnweb right now
> (https://svnweb.freebsd.org/socsvn/). Where do we have the things from
> before 2011?

We've had p4 back in the day; everything is still there, even p4web is
still up, summary and the links are at:

    http://wiki.freebsd.org/GSoC2007/cnst-sensors

Easiest way to bring back the code would probably be to simply pick up
the 3 commits from CVS src HEAD / SVN base/head:

    http://svnweb.freebsd.org/base?view=revision&revision=172631
    http://svnweb.freebsd.org/base?view=revision&revision=172632
    http://svnweb.freebsd.org/base?view=revision&revision=172633

History and background are available in my thesis:

    http://cnst.su/MMathCS
    http://uwspace.uwaterloo.ca/handle/10012/5234

> 
> There was at least in the past someone keeping it at least up-to-date, but I
> don't remember right now who/where.

IIRC, there were a number of people that tried maintaining it
henceforth, both publicly and privately, and the only issue you'd have
applying r172631 to -CURRENT would probably be a few simple merge
conflicts (Makefile etc), very simple to resolve.

There was a public thread from 2012 by avg@:

    http://lists.freebsd.org/pipermail/freebsd-arch/2012-October/013180.html

> 
> If someone is interested in the mail-thread of the past... available on
> request.

Actually, I think an mbox file is already publicly available from here:

    http://www.leidinger.net/blog/2009/12/06/freenas-sensors-for-freebsd

> -)

Cheers,
Constantine.SU.

http://Constantine.SU/

> 
> Bye,
> Alexander.
> --
> http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF
_______________________________________________
freebsd-hackers@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

[prev in list] [next in list] [prev in thread] [next in thread] 