[Smartmontools-support]Fwd: thoughts about CVS structure...

[Peter C. <pca...@ma...>]

[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
>