Hello Julia,
at last I have found some time to test your UDF implementation on
real-life blu-ray UDF images. Unfortunately, the results were not
completely satisfying. I have run the tests of your branch on AMD64 and
IA-32.
The first image I have tested seemed to be mounted fine (see the log
alois_nebel.txt attached), but the mount point (/mnt), which was
originally a directory, changed its type to a file (with a size of
458752 bytes, probably bogus). When I tried to to cat this "file" /mnt,
the VFS server crashed on the following assertion:
(node->type == result->type || result->type == VFS_NODE_UNKNOWN) in file
"vfs_node.c", line 221
The test with the second smaller image went the same (again see the log
bdrom.txt attached), the mount point changed its type to a file and when
accessing it the VFS hit the same assertion. I have also tried to mount
both images in Linux to make sure they are OK and the Linux UDF driver
accessed them fine.
As the second test image is "only" 5.8 GB in size, I'll send you a
private email later today with instructions how to download it, so you
can test it yourself. However, as it is a copyrighted material, I need
to ask you to use the image for debugging purposes only and refrain from
distributing it (simply treat it as if I were to lend you the physical
blu-ray disk).
Mounting an UDF image created by udftools still works fine on AMD64 and
IA-32, but your UDF driver seems to have some problems on big-endian
machines where it corrupts its own memory and crashes.
I have tested the mips32 big-endian port for GXemul, can you please look
into it as well? You should merge the mainline and add the "udf" and
"gxe_bd" binaries to the list of essential binaries to be able to build
a working boot image for big-endian GXemul. Remember that there is no
such preset profile, you need to select the "mips32 (GXemul)" profile
and then change the machine type from "lgxemul" to "bgxemul".
Finally, looking at your code there are still some minor coding style
issues (mostly similar to what I have already noticed a few weeks ago:
occasional missing spaces between operands, excess empty lines between
functions, etc.). But I believe this should take only a few minutes to
sort out.
I have also noticed that your branch on Launchpad hasn't been updated
for some time now. As the soft pencils-down deadline and ultimately the
final evaluation deadline are both closing quickly, I suggest that you
devote the time left primarily on bug-fixing of the read-only support,
possibly abandoning the read/write features for now.
A bug-free read-only support without any read/write capability is
probably more valuable than a buggy read/write support (at least as far
as GSoC and your final evaluation is concerned).
Also, please do not forget to merge with the mainline, so that your
branch can be easily integrated (merged back) after the deadline. Thanks!
M.D.
VRS: NSR found
VRS: end found
VRS success
Volume: Anchor volume descriptor found
Anchor: main sequence [length=32768 (bytes), start=32 (sector)]
Anchor: reserve sequence [length=32768 (bytes), start=16393216 (sector)]
Reading Volume Descriptor Sequence
Volume: Primary volume descriptor found
Volume: Implementation use volume descriptor found
Volume: Partition descriptor found
Partition number: 0, contents: '+NSR03', access type: 1
Partition start: 288 (sector), size: 16392896 (sectors)
Volume: Logical volume descriptor found
Logical Volume id: "ALOIS NEBEL", logical block size: 2048 (bytes)
Map table size: 70 (bytes), number of partition maps: 2
Volume: Unallocated space descriptor found
Volume: Terminating descriptor found
Volume[0]: partition [type 0] found and filled
Volume[0]: partition [type 0] found and filled
VRS: NSR found
VRS: end found
VRS success
Volume: Anchor volume descriptor found
Anchor: main sequence [length=32768 (bytes), start=32 (sector)]
Anchor: reserve sequence [length=32768 (bytes), start=2992608 (sector)]
Reading Volume Descriptor Sequence
Volume: Primary volume descriptor found
Volume: Implementation use volume descriptor found
Volume: Partition descriptor found
Partition number: 0, contents: '+NSR03', access type: 1
Partition start: 288 (sector), size: 2992288 (sectors)
Volume: Logical volume descriptor found
Logical Volume id: "BDROM", logical block size: 2048 (bytes)
Map table size: 70 (bytes), number of partition maps: 2
Volume: Unallocated space descriptor found
Volume: Terminating descriptor found
Volume[0]: partition [type 0] found and filled
Volume[0]: partition [type 0] found and filled
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
