From: Peter C. <pca...@ma...> - 2002-11-28 12:01:01
Attachments:
smart.out
|
[sorry - forgot to reply-all. Forwarding ....] Begin forwarded message: > From: Peter Cassidy <pca...@ma...> > Date: Thu Nov 28, 2002 10:58:25 Europe/Dublin > To: Bruce Allen <ba...@gr...> > Subject: Re: thoughts about CVS structure... > > 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. > > 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. 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? > > 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. > > 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 ... > > 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. > > 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. > > The project is looking like this right now; > > 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? > > 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! > > Regards, > > Pete C > |
From: Bruce A. <ba...@gr...> - 2002-11-29 05:13:52
|
Hi Peter, 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 that reason. > > 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 ... Cool. > > 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 it. > > 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 booted. 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 need these. [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. Exactly. > > 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. Cheers, Bruce |