Detecting exploding batteries, part 2

[David Zeuthen]

On Mon, 2006-09-25 at 14:15 +0200, Danny Kukawka wrote:
> On Monday 25 September 2006 13:47, Soren Hansen wrote:
> > On Mon, Sep 25, 2006 at 11:08:44AM +0200, Danny Kukawka wrote:
> > > What's the next key in HAL? computer.your_disply_can_fail or
> > > storage.you_harddisk_die_maybe_in_2_years?
> >
> > Actually, it might be a good idea to have HAL look at S.M.A.R.T values
> > and make and set a "device_failure_imminent" might make good sense.
> 
> And es next we implement postfix in HAL ... or the kernel ;-)

Of course not. Don't be silly :-)

But it does make sense for desktop apps to show this kind of information
and the right thing here is to call into HAL I think. I'm planning to
show this information in the gnome-diskutil I'm working on too

> For this we have smartd, we don't need to reimplement this logic in HAL:

So, I am not going to re-implement something if there is code out there
which is better and easy to integrate into HAL. Case in point are UPS's
- it makes a ton of sense that the NUT project is integrating with HAL.

> <qoute>
> smartd is a daemon that monitors the Self-Monitoring, Analysis and Reporting 
> Technology (SMART) system built into many [...] hard drives. The purpose of 
> SMART is to monitor the reliability of the hard drive and predict drive 
> failures [...] smartd will attempt to enable SMART monitoring on ATA devices 
> [...] and polls these and SCSI devices every 30 minutes, logging SMART errors 
> [...] In  addition to logging to a file, smartd can also be configured to 
> send email warnings if problems are detected.  [...]
> </quote>

So I see us either 

 1. talking to the smartd people about HAL integration (make smartd a
    hal addon) - shouldn't be much work

 2. or use just call into smartd ourselves via the tools they provide

Last time I looked smartd suffered from the same symptoms that other
user space low-level software / driver software suffers from: 

 - they are designed with little thought of integration into frameworks
   or UI applications

 - typically they require the admin to write out configuration files.
   It gets funny when things like the installer, yast, system-config-*
   whatever tries to do this. 

   [insert old story about why configuration files are fundamentally bad
    for things like this including .rpmnew etc.]

 - To overcome configuration files, they often like to provide hotplug
   scripts / udev rules to put this kind of stuff in the wrong level
   of the stack.

To some extent this is a rant about open source in general :-). Anyway,
this sounds like a fun project that will also teach the implementor a
lot about of HAL works. Any takers? :-)

[on the same note we, the HAL project, ought to participate more in
bounties, Google summer of code etc. for projects like these]

     David