A couple of questions:
(1) Have you thought about the fact that smartmontools supports many
operating systems other than Linux?
(2) Are you volunteering to do the work described below (and ensure that
smartmontools continues to work on all the supported operating systems)?
On Sat, 25 Aug 2007, Trollen Lord wrote:
> This is something that I probed into actually and it is quite doable. I am
> however not convinced that it is a wise solution in the long run. Adding
> further complexity into that snowball that is rolling down the hill does not
> seem wise.
> I took some time to review the source code through. It is imho in such state
> that would warrant a complete re-design and re-implementation. The present
> version is too old and decayed. I will try to give some thoughts for this.
> - The library part and the actual utility parts are not properly separated,
> making working with it unnecessarily complex. I would split it entirely into
> libsmart and the rest.
> - It is at some parts a compiler preprocessor hell and too complex. You can
> see it from some of the comments already "ohh, xxx tried to add this feature
> but it broke this another feature so I removed the new feature". What I
> would suggest is building an architecture that abstracts things and uses
> other methods (besides the preprocessor mess of today) whenever possible for
> platform differencies.
> - There is too much functionality. Although it seems like a nice idea of
> getting all sorts of nice hexadecimal dumps and readings from the devices in
> the end what is important is a) enabling SMART reliably on all devices b)
> (optionally) initiating some test c) reporting of imminent and potential
> failures. You can happily remove 2/3 of that absolutely unnecessary plain
> gold plating from the tools that it has today, making the maintenance of the
> primary requirement related code significantly easier and the code more
> reliable and less complex.
> - Uncoupling smartd and the other utilities from actually handing the
> reporting could be useful and should be done using dbus.systembus. It's a
> suitable (easy, ready, maintained, reliable, light, portable) solution for
> both desktops AND servers, making ie. KDE and Gnome folks at last being able
> to include default support for noticing the end users of failures etc. Also
> it would make easier building some modern server monitoring solutions, which
> as oss do not exist at this moment.
> - Libhal (yet an other freedesktop.org standard, which is portable etc) can
> offer an unambiguous way of referring into devices (which is why libhal
> exists) which is well thought and good to work with.
> - These solutions would also be able to handle hot-pluggable drives on
> heavier server hardware with almost the same effort, getting SMART enabled
> automatically and the monitoring to work etc.
> What I would really honestly suggest that every maintainer/developer would
> start working on is a modern clean room implementation into which only the
> hardware specific definitions will be used from the present implementation.
> It is actually literally the *only* hope for ever getting SMART monitoring
> enabled out of the box for any Linux distributions. There are no other
> solutions for doing that at all, and the present one is simply not something
> you can package and include.