fs: new filesystem implementation VXEXT1.0
PATCH 1/1 fs: new filesystem implementation VXEXT1.0
Hi,
The following URL is link to a large patch for a possible integration of a new filesystem implementation in the misc section of the kernel tree. It features a reverse engineered implementation of the so called VXEXT1.0 DOS filesystem which is commonly used on VxWorks RTOS systems from Wind River Inc., where the "extended DOS filesystem" mode is enabled.
The VXEXT filesystem is more or less a FAT16 based filesystem which was slightly modified by Wind River to allow the storage of more than 2GB data on a partition, as well as storing filenames with a maximum of 40 characters length. To achieve that, VxWorks uses a dynamic cluster size calculation which is based on the partition size where clusters can be larger than 32K. In addition, it uses a slightly modified directroy entry structure to allow to store filenames larger than 8+3 characters.
Please find the patch file accessible through the following URL:
http://www.jens-langner.de/vxext_fs/vxext_fs_1_0-linux-2.6.11.4.patch
In addition, refer the detailed technical documentation on my implementation and the root directory of my distribution as well:
http://www.jens-langner.de/vxext_fs/Documentation/vxext.txt
http://www.jens-langner.de/vxext_fs/
Please note that large portions of the implementation are based on the already existing FAT16 (msdos) implementation in the kernel tree. However, instead of patching/drilling the original FAT16 implementation, an "outsourced" rework for developing the VEXT implementation was considered.
cheers,
jens
Signature · 4 lines
Jens Langner Ph: +49-351-4716545 Lannerstrasse 1 01219 Dresden [email protected] Germany http://www.jens-langner.de/
Quoted 4 lines · Jens Langner
Hi,
The following URL is link to a large patch for a possible integration of a new filesystem implementation in the misc section of the kernel tree.
If you like people to review it te best thing to do is to break it up in smaller logical selfcontained pieces (not just file-by-file) and post these. People on this mailing list seldom follow URL's.
Sam
Quoted 5 lines · Sam Ravnborg
Quoted 1 line
The following URL is link to a large patch for a possible integration of a new filesystem implementation in the misc section of the kernel tree.
If you like people to review it te best thing to do is to break it up in smaller logical selfcontained pieces (not just file-by-file) and post these. People on this mailing list seldom follow URL's.
Sorry, but as the patch is a complete new implementation the patch file is almost 110KB long. So I thought it might be a better idea to just post an URL. Also the "Documentation/SubmittingPatches" file in the kernel tree does suggest to just post an URL if the files are too large. And IMHO 110KB is quite large, isn't it? ;) But if someone wants me to submitt the whole patchfile, I can of course do so.
cheers,
jens
Signature · 4 lines
Jens Langner Ph: +49-351-4716545 Lannerstrasse 1 01219 Dresden [email protected] Germany http://www.jens-langner.de/
Quoted 4 lines · Jens Langner
The VXEXT filesystem is more or less a FAT16 based filesystem which was slightly modified by Wind River to allow the storage of more than 2GB data on a partition, as well as storing filenames with a maximum of 40 characters length.
Can this not then be folded into the existing vfat filesystem?
Quoted 6 lines · Chris Wedgwood
Quoted 4 lines
The VXEXT filesystem is more or less a FAT16 based filesystem which was slightly modified by Wind River to allow the storage of more than 2GB data on a partition, as well as storing filenames with a maximum of 40 characters length.
Can this not then be folded into the existing vfat filesystem?
Sure it can. But I thought that as the VXEXT1.0 filesystem is per definition not a vfat filesystem it might be better to have it separated and not drill it into the IMHO anyway overly mixed up vfat/fat code already in the linux kernel tree. Even if that means that some parts in the code of the vxext filesystem are probably equal to the msdos implementation, please note that large parts which were not needed by the vxext implementation was dropped by me for clarifications.
So I still hope that my implementation is going to be considered for a future kernel tree integration as it may be quite usefull for embeeded systems wanting to access VxWorks partitions.
cheers,
jens
Signature · 4 lines
Jens Langner Ph: +49-351-4716545 Lannerstrasse 1 01219 Dresden [email protected] Germany http://www.jens-langner.de/