Hi Charles,
Oh, surely - I use it at least once on every box I install (to turn on DMA for CD-Rom drives - something Redhat doesn't enable by default). What I meant was that I was not going to spin down the harddisks on my "main" devel box, and my LEAF devel box has no harddisk (just CF). So, I can't confirm that it won't segfault when trying to spin down the disk due to some misconfiguration during the build process. Of course, I _can_ see if hdparm will start and if it will display the current settings of an IDE device (and I surely will) on an uClibc box, but I guess we both know that "it compiled ok and it didn't segfault straight away" doesn't mean one has actually tested the program ;-)I can give it a shot tomorrow evening (CET). I've made the "hdsupp" package (with fdisk and so on) for bering uClibc, and I guess hdparm would fit in there too (as I recall, we even discussed that among the uClibc developers, but decided against putting that in, since we didn't see much use for it (none of us is using "real" HDs, only CF discs, which is probably why we didn't see much use for it.))
I'll let you know when I have a binary (I'm afraid I won't be able to test it, since none of my uClibc boxes have a harddisk).
You should be able to test it. hdparm will dump a report on pretty much any IDE device. While you won't be able to test spinning down your flash disk, you can run lots of other tests.
I personally find hdparm useful for any system running IDE devices, if for nothing else than to verify IDE modes, dma usage (or not), read-ahead, multi-sector operation, and the speed tests. All of these should work on pretty much any IDE device, not just a mechanical hard-disk.
And my guess is that Dietmar would be willing to play beta tester rather than wait until monday or even later, when I've had time to do any serious testing.
In short, what I meant was that I won't be able to do the kind of testing that deserves being called "testing" for me - most of the projects I work on for my job require fully documented verification and validation, and even thought I would never consider doing that kind of stuff for an opensource project on a friday night, "testing" to me still means running through as many test cases as possible, which is obviously not something I'll be able to do by tomorrow night (especially since I will not be able to work on that during the day).
Martin
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
