Common interface for sensors/health monitoring

Antony Mawer lists at mawer.org
Mon Aug 24 01:01:15 UTC 2009


On Mon, Aug 24, 2009 at 2:38 AM, Marc Balmer<marc at msys.ch> wrote:
> Am 23.08.2009 um 18:24 schrieb Alexander Leidinger:
>> On Sun, 23 Aug 2009 17:13:42 +0200 Marc Balmer <marc at msys.ch> wrote:
>>> Am 23.08.2009 um 17:08 schrieb Alexander Leidinger:
>>>> On Sat, 22 Aug 2009 21:02:32 +0200 "Aurélien Méré"
>>>> <aurelien.mere at amc-os.com> wrote:
>>>>
>>>>> I'm just afraid by reading your email that the situation doesn't
>>>>> seem to have evolved since the discussion regarding the SoC, maybe
>>>>> even more taboo, and that I'll have to keep writing my own
>>>>> software and drivers to get the data I want in the future if I
>>>>> want to get this data under FreeBSD.. Is it the case ?
>>>>
>>>> It is not "taboo", it is just that nobody wants to spend his spare
>>>> time
>>>> with something like this now.
>>>>
>>>
>>> I hope people spend their time on thinking what was bad with the
>>> sensor framework last time and improve on that, instead.
>>
>> Go and read in the archives about it, maybe you understand why
>> there's not much motivation to spend spare time on such a topic.
>
> Everyone should have the right to come back with a subject, if work is put
> into it.  Or is the stanza that once there has been a heated discussion
> about a topic, there is no possibility to come back to it, maybe making it
> better a seccond time?  And no, I have no plans to do so... I am just a bit
> astonished about the attitude...

I for one would be quite happy to contribute towards such an effort. I
would much rather contribute towards a project-wide monitoring
solution rather than continuing to extend/maintain my own ad-hoc
monitoring scripts. I am sure many others are in a similar position...
it seems crazy that we are all re-inventing the wheel instead of
contributing to a common effort.

Is there a summary (perhaps something suitable to go on the Project
Ideas page) that outlines:

- An outline of what such a system should provide
- What it should NOT provide (ie. what would be "out of scope")
- What lessons should be learned from the SoC effort (ie. both good
points and what NOT to do)
- Suggested starting points

Maybe that would go a long way to ensuring anyone wanting to start
such an effort without getting to the end and having their efforts
rejected... Yes, bits of this can be found in the past mailing list
posts, but it would nice to have an clear "official" summary of this
so that any volunteer effort has the best chance of being accepted...

-- Antony


More information about the freebsd-hackers mailing list