Date: Wed, 11 Jul 2007 11:45:26 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org Cc: Rui Paulo <rpaulo@fnop.net>, Shteryana Shopova <syrinx@freebsd.org>, "Constantine A. Murenin" <cnst@freebsd.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Robert Watson <rwatson@freebsd.org>, Alexander Leidinger <Alexander@leidinger.net> Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD Message-ID: <200707111145.27741.jhb@freebsd.org> In-Reply-To: <20070711134959.2q3akd4zk0o8404c@webmail.leidinger.net> References: <55754.1184143579@critter.freebsd.dk> <20070711104247.P58526@fledge.watson.org> <20070711134959.2q3akd4zk0o8404c@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 11 July 2007 07:49:59 am Alexander Leidinger wrote: > Quoting Robert Watson <rwatson@FreeBSD.org> (from Wed, 11 Jul 2007 > 11:12:24 +0100 (BST)): > > > On Wed, 11 Jul 2007, Poul-Henning Kamp wrote: > > > >> In message <469420B9.20401@FreeBSD.org>, "Constantine A. Murenin" writes: > >> > >>> If you want to have no such framework that could potentially > >>> diagnose or predict system failure, it's your choice, [...] > >> > >> I would love to have that, but the OpenBSD code isn't that. > > > > In the general spirit of SoC, I would suggest that a more constructive > > line of commenting might come with suggestions, not just rejections > > :-). Are you arguing that the current proposed framework offers little > > incremental benefit over simply having the sysctl framework in the > > first place and having each source of information (i.e., device driver) > > just export it directly? > > > > It seems clear that people would like all these measurements to be > > available, even if not by the precise mechanism proposed. So far the > > specific technical criticals have been: > > > > - There's such a diversity of motherboard devices and probe mechanisms that > > any kernel driver would become rapidly over-burdened and needlessly > > complicated. > > > > This doesn't argue for doing nothing, just that perhaps a kernel device > > driver is the wrong place. > > On the other hand you don't want to allow an userland tool to directly > mess around with the registers on your RAID or NIC to get some status... Err, that's how all the RAID utilities I've used work. They send firmware commands from userland and parse the replies in userland. One exception I've seen so far is that for software RAID the firmware you are talking to is the driver, not firmware on the card, so you use ioctls directly rather than an ioctl that sends a command to the firmware on the card. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200707111145.27741.jhb>