On 2014-02-19 11:27, Andre Marques wrote:
Sorry for the delay.
I'm almost ready to send the patch with the test, but there are some questions.
This is nice.
On 02/10/14 08:14, Sebastian Huber wrote:
Hello Andre,
thanks for the test case.
On 2014-02-08 13:26, Andre Marques wrote:
Hi,
As discussed in [1], I created a new fstest to check the rename()
implementation against the POSIX specification [2].
What the attached patch does not test:
- Testing the existance of a link visible to other processes during the rename
process (ensuring that there is always a reference to the file). Not sure about
the best way to test this.
The file system instance is locked during the rename operation, so other
threads cannot interfere here.
Should I test the lock then?
I think a test would be quite difficult. I would postpone this.
What happens if you rename a file with an open file descriptor should be tested.
That is already covered on the test.
- Testing that after all processes close their references to a file after it
was removed by rename() the file contents are removed (or marked as free space,
I guess). I only found platform dependent ways of dealing with disk block's.
Maybe you can use the statvfs() function for this.
The statvfs() function gives "not implemented" on the IMFS filesystem, so I
changed the used filesystem to MOUNTED RFS.
Ok, maybe we should implement this function for the IMFS or skip the test case
if statvfs() is not available.
- Testing errno values in error situations. There is already a fstest named
fserror which purpose seems to be checking errno values for a bunch of
functions (rename included, but with some errno values missing). Not sure if I
should put them in this test or add to fserror.
I would move all rename related tests to this new test program.
About the errno value testing, I'm currently missing EIO, ENOSPC, EROFS and
EXDEV.
EROFS and EXDEV require mounting a second filesystem. How can I do this in
RTEMS? Can it be done at runtime? I've been looking at the fileio sample, which
uses the fsmount() function, but I need a disk to mount with it.
For EROFS there is already a test in fstests/fsrofs01.
You can mount as many file system instances as you want. You can do this with
mount(). The mount() parameters are file system dependent. The generic file
system tests (and your rename test should be one of them) use a support file
for this:
./testsuites/fstests/mrfs_support/fs_support.c
./testsuites/fstests/mimfs_support/fs_support.c
./testsuites/fstests/mdosfs_support/fs_support.c
./testsuites/fstests/imfs_support/fs_support.c
./testsuites/fstests/jffs2_support/fs_support.c
You can use the system file system as the second file system for the EXDEV test.
For ENOSPC I'm thinking in mounting a small disk and testing that way, but for
EIO I don't know how to simulate a physical error. How can I generate an I/O
error?
Generating an IO error will be difficult or impossible (e.g. for IMFS). For
the disk device based file systems you need a special driver. I would ignore
this for now.
This test uses the MOUNTED IMFS filesystem, for no particular reason, so if
that's an issue please let me know.
[1] - http://www.rtems.org/pipermail/rtems-users/2014-January/012378.html
[2] - http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html
--André Marques
[...]
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
