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

On Wednesday 11 July 2007 07:49:59 am Alexander Leidinger wrote:
Quoting Robert Watson <rwatson@xxxxxxxxxxx> (from Wed, 11 Jul 2007
11:12:24 +0100 (BST)):

On Wed, 11 Jul 2007, Poul-Henning Kamp wrote:

In message <469420B9.20401@xxxxxxxxxxx>, "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
_______________________________________________
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: pci powerstate related: aac(4) broken on Perc 3/Di on -CURRENT
    ... One thing to keep in mind with the Dell PERC systems is that the RAID ... Anywhere from 0 - 2 devices of this SCSI chip are ... them to something that the ahc driver will not attach to. ... So why is the aac firmware getting mad? ...
    (freebsd-current)
  • Re: SA3200 Disk array controller in PC (was: 5300 Disk array controller in PC)
    ... I think I was talking Firmware - not Driver. ... Use RAID 5 and keep the extra drive as a spare. ... So you'll notice a failed disk when you do your daily backup. ...
    (comp.sys.hp.hardware)
  • Re: Porting OpenBSDs sysctl hw.sensors framework to FreeBSD
    ... that's how all the RAID utilities I've used work. ... commands from userland and parse the replies in userland. ... let a user run such a tool (and nowadays even desktops start to have ... Whatever talks directly to the driver needs to run as root, yes, but you could ...
    (freebsd-arch)
  • Re: Fedora 9 Boot Problem
    ... see the section on Firmware / Driver based RAID ... Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines ...
    (Fedora)
  • Re: [PATCH][2.6][2/14] documentation update
    ... add udev.txt which describes how to use dvb and udev/sysfs ... The firmware can be loaded automatically via the hotplug manager ... +- For the dvb-ttpci driver/av7110 card you can download the firmware files from ... +file you probably know from the 2.4 DVB releases driver. ...
    (Linux-Kernel)