On 02/19/14 14:00, Sebastian Huber wrote:
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.
Skipping for now.
- 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.
So I leave EROFS out of this test?
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
Yes I'm using support files on Makefile.am.
For mount() should I use a ramdisk for the device file?
I tried to create a ramdisk as in
http://www.rtems.org/onlinedocs/doxygen/cpukit/html/group__rtems__ramdisk.html#gac6c99eed9f3b92bb4cf5184b25972e65
but the program exits during the rtems_blkdev_create() call, if I use
"/dev/rda" as the device path.
You can use the system file system as the second file system for the
EXDEV test.
I'm reading this as mounting an instance of the system filesystem. Am I
right?
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
[...]
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
