Sorry for the slow reply. I've been working on some data analysis code...
> > On Thursday, Nov 28, 2002, at 09:19 Europe/Dublin, Bruce Allen wrote:
> >> Hi Peter,
> >> I've been thinking a bit more about CVS structure. One possibility is:
> >> CVS www/
> >> sm5/ Most stuff
> >> sm5-darwin/ Makefile, atacmds.c iokitheaders.h ...
> >> This has the advantage that it leaves existing CVS structure and linux
> >> stuff alone. The disadvantage is that the CVS download instructions
> >> for
> >> darwin wouldl read differently, and it introduces an asymmetry between
> >> platforms.
> >> Another possible structure would be something like:
> >> CVS www/
> >> sm5/ platform/ macos/ atacmds-darwin.c iokitheaders.h ...
> >> linux/ atacmds-linux.c
> >> src/ common code
> >> This has the advantage that the CVS build/download instructions could
> >> read
> >> the same for different OSes. It also allows trivial extention to
> >> other
> >> OSes and architectures. The disadvantage is that it requires some
> >> restructuring of CVS and the existing linux Makefile, and a bit more
> >> restructuring of the code since include paths will change.
> > Hi Bruce,
> > [I'm going to try to address as much as I can in this note]
> > The latter option seems to be looking the best right now. It would
> > certainly make future ports a lot simpler if the platform-specific
> > stuff was abstracted & the Makefile handled the specifics. Right now,
> > I've almost all the SMART commands ported over in atacmds.c but it
> > looks a horrible mess (enclosed!). It's crying out to have the
> > low-level access pulled out. The file, as it is now, would be
> > difficult for both the Linux and MacOSX maintainers as they'd both be
> > extremely conscious of stepping on each other's code.
Fair enough. I think that this is also my prefered solution, for just
> > If you like, it might be better to leave sm5 alone for the moment &
> > let the rest of your guys work away as normal. Set up another
> > sm5-darwin, as suggested & I'll have the job of keeping it in sync
> > with the main branch.
OK, if you're comfortable keeping things in sync, this makes it easy for
the rest of us!
> > I've already checked out the latest from CVS &
> > re-merged. The stuff I'm doing will be multi-platform so the idea
> > would be that adventurous souls could check out my stuff and verify it
> > against the main branch. When everyone is comfortable with the
> > multi-platform version, we can merge it back into sm5 (should be easy
> > as it'll be in sync) and kill off the Darwin branch. Thoughts?
This makes it easy for me (and everyone else as well). Let's do it.
> > Right now, I can run smartctl and have it work successfully with out
> > the ataIdentify. I've enclosed a dump of stdout. Must say, I'm
> > impressed with the app & the level of detail it provides! Cooler than
> > I thought .... So right now, smartctl is working on MacOSX but needs
> > some stuff fixed & I need to go through all the options & verify that
> > they're all ok.
I spotted a couple of strange things in the output. I'll write about
those things separately. By the way, I bet you've got an IBM disk, right?
[Three temperatures gives it away.]
> > The SMART daemon smartd is getting carried along as I work on
> > smartctl. Right now, it's working, too. Getting back to the
> > platform-specific stuff, the init process for MacOS X is unlike any
> > other *NIX - there's no concept of rc.x files or init.d. However, I
> > can handle all this in the platform-specific make-and-install stuff.
> > The MacOSX will have the daemon start up just like any other & it will
> > display the proper stuff in the startup window, etc ...
> > SCSI should come along, too. Fortunately, the IOKit routines for SCSI
> > appear at first glance to be conventional enough (SCSITaskFile,
> > SCSICommand, etc) so there shouldn't be too many problems. I'll wait
> > until the ATA stuff is stable first, tho'. There are a few SCSI
> > machines I can get my hands on for test ...
That's great. I have done virtually no work on the SCSI code -- but I
have ordered a SMART-capable SCSI disk to play with so I can at least test
> > Reckon we might be able to work around the ataIdentity issue as there
> > appear to be IOKit accessors available for the information we require.
> > It'd be just a matter of accessing the appropriate records and bending
> > the results into your hd_driveid structure.
The hd_driveid structure is straight from the ATA specs, so this shouldn't
be too hard. The ATA specs define a 256 word (512 byte) structure, all
returned in a single call, so somewhere in the guts of IOKit, the data is
already there in exactly the correct format -- it's the only way that the
drive actually delivers it.
One thing to be careful about. The DriveID data is dynamic. It contains
some fixed fields that never change, and other fields that DO change over
time. As well as a checksum that changes too. On many systems the BIOS
makes a copy of the DriveID data on bootup, and there is typically an OS
call that returns this -- the DriveID structure at the time the system was
Don't accept this solution -- hold out for the genuine article -- a
DriveID data command that returns the 512 bytes from the disk at the
instant it is called, not some memory of what was there on bootup. There
are some variable entries in the DriveID structure that will change -- for
example the entry that shows if SMART is enabled or not. You want and
[By the way, ss PPC the same or opposite endian order from x86? If it's
different, we will need to drop a bit of byte swapping code -- see
printswap() in ataprint.c]
> > I've written a cross-platform configure script that will pull up the
> > correct Makefile & other files according to needs. So you run
> > ./configure, make clean, make, make install. make install needs some
> > work to function on MacOS X as many of the paths are different and the
> > startup config is wildly different. I've most of that done.
> > smartd.conf is different, too.
OK. Hopefully you've done this in a way that makes it easy to add
additional platforms in the future.
> > configure
> > atacmds.c
> > README
> > ...
> > ...
> > os
> > - linux
> > - Makefile
> > - smartd.conf
> > - macosx
> > - Makefile
> > - smartd.conf
> > - macosx.h
> > ... and so on. If you like, I can abstract all the platform-specific
> > stuff out & put it in the appropriate os directory. The config script
> > will transparently handle all that & it would be simpler for the
> > developers to manage & the project would get a lot less spaghetti-like
> > as platforms proliferate. *And* Linux developers wouldn't have to see
> > a line of IOKit code unless they wanted to! Thoughts?
This seems wise. In any case, when everything is visible in sm5-darwin/,
I'm sure that Erik and I will both have some comments and suggestions.
Once it's all converted you can merge it back into sm5/.
> > The three lines of code you use in smartctl.c to open the target
> > mushroom out to about 30+ on MacOSX & thus would be an ideal candidate
> > for abstraction.
> > Thanks for adding me to the developer list, BTW!
Well, thanks for doing all this work!
I'll put my comments about getopt_long() and your initial smartctl output
in a separate message.
Please tell me if you want to set up sm5-darwin yourself using "cvs
import" of your existing tree, or if you want me to make an empty
directory that you use "cvs add" to put stuff into.
Oh, and please put a big warning in capital letters at the top of your
README file saying "this is a test and development directory for .... If
you want the stable production version of smartmontools for linux please
go to ...." as a guide to the lost and/or clueless.