Date: Wed, 11 Jul 2007 19:05:46 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Cc: Rui Paulo <rpaulo@fnop.net>, Shteryana Shopova <syrinx@FreeBSD.org>, freebsd-arch@FreeBSD.org, Robert Watson <rwatson@FreeBSD.org>, "Constantine A. Murenin" <cnst@FreeBSD.org> Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD Message-ID: <20070711190546.4b202080@deskjail> In-Reply-To: <56736.1184162080@critter.freebsd.dk> References: <20070711144240.a3gdtxjvqcwkg4o4@webmail.leidinger.net> <56736.1184162080@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting "Poul-Henning Kamp" <phk@phk.freebsd.dk> (Wed, 11 Jul 2007 13:54:40 +0000): > In message <20070711144240.a3gdtxjvqcwkg4o4@webmail.leidinger.net>, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070711190546.4b202080>