Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD

Quoting "Poul-Henning Kamp" <phk@xxxxxxxxxxxxxx> (Wed, 11 Jul 2007 13:54:40 +0000):

In message <20070711144240.a3gdtxjvqcwkg4o4@xxxxxxxxxxxxxxxxxxxxx>, Alexander Leidinger writes:

I was not thinking about 7-layer-OSI, I was thinking about 3 layers:
presentation, infrastructure and "low-level" data acquiring stuff (I
prefer the pragmatic way of looking at things).

This again misses the point, because you assume a simple bottom-up
architecture will work like it does for PCI devices.

In this case however, the majority of systems need some piece of code
to identify them, look up in a table (which we get from where ?) and
configure the sensors.

Sensor hardware is not context-free and selfidentifying like PCI and
USB devices, in fact, it is about as far from PnP as you can get.

Finding an LM75 and reading the temperature is worth next to nothing
if you don't know where the LM75 is mounted.

Reading an ADC is worth absolutely nothing, if you don't know what
it measures and what voltage dividers are in front of it.

Finding an I2C sensor and trying to read it is a catastrophe when
it turns out not to be a sensor but the motherboard clock generator
or voltage regulater.

You are focusing on physical devices which are specially build as a
sensor for some specific stuff. I put my focus on the kernel framework
which allows to unify the handling of sensoric data from kernel
devices. This is a difference. You are talking about stuff which really
needs to be handled in userland. I talk about stuff like instrumenting
cam to use the sensors framework to present interesting data of SCSI
devices/enclosures/whatever in an unified way, about instrumenting
gvinum/gmirror/graid/whatever to provide status information, ...

You are talking about stuff which belongs into userland and which
collects sensoric data which comes from either userland devices which
reads temperature sensors like LM75 _and_ from e.g. the hw.sensors
framework this thread is all about.

The presentation layer which you talk about in my opinion when you talk
about namespaces, would use several infrastructure layers in parallel,
and the framework we are talking about would be one of those
infrastructure frameworks.

To me it sounds like we are talking about a bottum-up vs. a top-down
approach. You need to get some information from existing kernel devices
out of the kernel to feed it into "your sensors framework", and this
GSoC project is about this. And it seems to me that you say we should
start with the userland part and do the kernel part when we have
everything done what can be done in userland. But this is not what the
proposal was all about when we rated the GSoC projects.

It may be the case that the use of the temperature sensor we've seen
here for the testing of the framework is not a good idea because the
temperature sensor reading code belongs into the userland, but I think
for development purposes to get the framework integrated in a sane way
without breaking other stuff, it is not bad. When the kernel framework
works as intended, work can start to enhance existing drivers which can
present some interesting data via this framework. I talk about data
which can not and should not be collected by an userland program
directly.

I hope this clarifies my view of the things at hand.

IFF we want to do something more comprehensive than the gaggle of
ports, then we want to do it properly so that it doesn't weigh down
the kernel with tons of, on average unused, junk, doesn't imperil

I agree.

hardware and delivers sensor readings which come with the necessary
context to have a real physical meaning.

I'm sure the framework can be enhanced to deliver some meta-data from
the driver where the data is collected to the userland. But before the
framework can be extend I think it is important to get it up and
running. And AFAIK getting it up and running is what this GSoC project
is about.

Access to I2C busses and I/O registers should happen in the kernel,
but maintaining a database of all sorts of weird systems should not.

I agree.

The more important question ATM is probably: Do you or I or Robert, or
whoever lurks and has an opinion have/has the right expectations about
what this framework is about?

Bye,
Alexander.

--
Isn't air travel wonderful?
Breakfast in London, dinner in New York, luggage in Brazil.
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: sensors framework continued (architecture)
    ... This sounds like you propose more than one kernel access point for all ... I was talking about the one fd per sensor part here, ... With just one syscall (see above for the sysctl approach) you can not ... do latency measurement in userland. ...
    (freebsd-arch)
  • Re: sensors fun..
    ... 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. ... I will answer to your mail where I talked about access to ISA stuff as time permits, and I try to do it in a verbose way so that the picture about Constantine's sensors framework is more clear. ...
    (freebsd-arch)
  • Re: sensors fun..
    ... as I don't think userland data should be feed into the kernel. ... Nowhere do I suggest to feed userland data into the kernel just so it can be ... a sensor implemented in the kernel. ...
    (freebsd-arch)
  • Re: sensors fun..
    ... as I don't think userland data should be feed into the kernel. ... a sensor implemented in the kernel. ... Now I think that you talk more or less about something which could be implemented e.g., as an userland library which not only polls the kernel sensors framework, but provides the single-system sensor data. ...
    (freebsd-arch)
  • Re: sensors fun..
    ... 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. ... what the soc project was about. ...
    (freebsd-arch)