On Jan 9, 2014, at 5:51 PM, Paul Hargrove <[email protected]> wrote:
> Nevermind that - I just recalled that test/util/opal_path_nfs.c is
> Linux-specific. So, there won't be any testing coverage of the new code on
> any of my Solaris or BSD systems. Nor will Mac OSX get any "real" testing.
>
> Does anybody have suggestions (assuming I can mount an NFS dir on each of my
> systems) as to how one might verify that the revised opal_path_nfs() is
> *correct* on the BSDs and Solaris?
I just updated the test/util/opal_path_nfs.c test as follows:
On all platforms, if you provide one or more command line options,
each command line option is given to opal_path_nfs() and the result
is sent to stdout.
For example, if you build and run the test like this:
make check
./opal_path_nfs . Makefile ~
It'll report if ., Makefile, and ~ are on network filesystems (i.e., the result
of sending each of ".", "Makefile", and "your_home_dir" to opal_path_nfs()).
> If there is no validation possible, then it might be safer for 1.7.4 to leave
> the no-op behavior. However, as far as I can tell opal_path_nfs() is
> currently used ONLY for by shmem/mmap to *warn* about mapping files on
> network filesystems. So, maybe this isn't critical at all.
Correct. Which is why a huge effort wasn't undertaken to automate it on
non-Linux platforms. But I think adding the interactive tests for all
platforms is helpful.
> I *will* make a point of NOT setting OMPI_MCA_shmem_mmap_enable_nfs_warning=0
> as I normally do in my testing (thought I can't remember why I added that to
> my testing scripts in the first place). Then at least I might be able to
> tell if opal_path_nfs() is returning false positives.
Cool; thanks.
--
Jeff Squyres
[email protected]
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
