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
--
Jens Langner Ph: +49-351-4716545
Lannerstrasse 1
01219 Dresden [email protected]
Germany http://www.jens-langner.de/
On Thu, Mar 17, 2005 at 04:16:36PM +0100, Jens Langner wrote:
> 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
Sam Ravnborg wrote:
>>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
--
Jens Langner Ph: +49-351-4716545
Lannerstrasse 1
01219 Dresden [email protected]
Germany http://www.jens-langner.de/
On Thu, Mar 17, 2005 at 04:16:36PM +0100, Jens Langner wrote:
> 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?
Chris Wedgwood wrote:
>>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
--
Jens Langner Ph: +49-351-4716545
Lannerstrasse 1
01219 Dresden [email protected]
Germany http://www.jens-langner.de/