Extracting Dosfs

[Bogdan Vacaliuc]

My attachments got rejected again.  Grr, even though they were plain text.  Here are links to get them if you are interested:

http://www.ngit.com/pub/101704/bv1_rdcf2.patch
http://www.ngit.com/pub/101704/bv1_rdcf2.log
http://www.ngit.com/pub/101704/Makefile
http://www.ngit.com/pub/101704/rdcf2.awk

-bogdan

-----Original Message-----
From: Bogdan Vacaliuc
Sent: Saturday, October 16, 2004 1:05 PM
To: 'Daniel Gustafsson'
Cc: 'rtems-users at rtems.com'; 'pje at efgh.com'; 'Etienne Fortin'
Subject: RE: Extracting Dosfs


Daniel, Philip,

Here is a patch (and additional files) to the distributed RDCF2.0 to make it 'compile readily' under GNU (Tested on Cygwin, Debian
GNU/Linux):

1) Get the distributed rdcf2.txt from (http://alumnus.caltech.edu/~pje/rdcf2.txt)

NOTE: On GNU/Linux, you will have to convert this file to unix line endings with dos2unix, flip -u, etc, in order for patch to work
properly (It was a hassle to get patch to work with DOS files).  On Cygwin, it seems to be handled gracefully; YMMV.

2) Save the (attached) files in the same folder as the above.

[/tmp/rdcf2] ls
Makefile  bv1_rdcf2.log*  bv1_rdcf2.patch  rdcf2.awk  rdcf2.txt*

3) Apply the patch

[/tmp/rdcf2] patch < bv1_rdcf2.patch
patching file rdcf2.txt

4) Extract the files in the distribution

[/tmp/rdcf2] make unpack
awk -f rdcf2.awk < rdcf2.txt
readme.txt
cache.c
cache.doc
cache.h
files.c
files.doc
rdcf2.c
rdcf2.doc
rdcf2.h

5) Perform a confidence test

[/tmp/rdcf2] make confidence
#dd if=/dev/fd0 of=test.img bs=512 count=2880
dd if=/dev/zero of=test.img bs=512 count=2880
2880+0 records in
2880+0 records out
dd if=/dev/urandom of=FILE1.SRC bs=1 count=14872
14872+0 records in
14872+0 records out
dd if=/dev/urandom of=FILE2.SRC bs=1 count=72343
72343+0 records in
72343+0 records out
gcc -o files -DTEST_RDCF2=test.img cache.c files.c rdcf2.c
./files < test.vec > test.out
cmp FILE1.SRC FILE1.DST
cmp FILE2.SRC FILE2.DST
PASS


The confidence test builds a stand-alone implementation of RDCF2 and its command line test utility.  This test program includes a
file block driver which maps over a file.  I've added copyin/copyout and format to the command line test.  The utility is fed a very
simple test vector which formats the space, makes some directories, copies some files in and back out, then verifies that it got
what it started with.


*whew*

I wish I had done this bit of automation 2 years ago before I lost all the code.  My current code was of course integrated with its
respective project, so it couldn't be distributed/extracted easily.  Now we have a solid basis for making incremental updates to
RDCF2 so anyone can test it quickly (I hope).

The next step is for me to integrate the FAT16/2GB and Format code enhancements for Etienne, et. al.


Daniel, how is the DOSFS extraction from RTEMS going for you?

Best Regards,

-bogdan


On Thursday, October 14, 2004 9:02 PM, Bogdan Vacaliuc wrote:

> Ugh.
> 
>> inside an RTEMS environment.  The code is stand-alone and compiles
>> readily under GNU/Linux, Cygwin, etc.
> 
> I lied when I said it compiles readily.  Two years ago was when I
> started with it...  Funny, I remember whipping it together and
> demonstrating its functionality quite quickly.  Sigh.  I guess it
> will just take a little more time and coddling that I expected.   
> 
> -bogdan
> 
> 
> On Thursday, October 14, 2004 10:52 AM, Bogdan Vacaliuc wrote:
> 
>> Hi Daniel,
>> 
>> You may want to follow the ongoing "Formatting DOSFS volume" thread
>> in RTEMS: 
>> 
>> http://www.rtems.com/ml/rtems-users/2004/october/msg00086.html
>> 
>> The RDCF2 code (http://alumnus.caltech.edu/~pje/rdcf2.txt) may be
>> just what you are looking for if you are not interested in running
>> inside an RTEMS environment.  The code is stand-alone and compiles
>> readily under GNU/Linux, Cygwin, etc.
>> 
>> Best Regards,
>> 
>> -bogdan
>> 
>> 
>> On Thursday, October 14, 2004 9:37 AM, Victor V. Vengerov wrote:
>> 
>>> Daniel,
>>> 
>>> Have in mind that libblock depends on some RTEMS synchnorisation
>>> mechanisms, and run the thread writing blocks to the disk. Also,
>>> ms-dos file system and libblock has been designed with mulithreading
>>> in mind, which may be overhead for you. More free open-source MS-DOS
>>> implementations are exists (I remember freedos name, although I'm
>>> not sure) - may be it is better appropriate for you.
>>> 
>>> I don't know what are you going to implement, but it will be
>>> definitievly simpler to link your application with RTEMS,
>>> considering it as a library providing some services, particularly
>>> DOS file system. Nothing prevent you to implement single-threaded
>>> application in RTEMS - just run it as a initialisation task.
>>> 
>>> Victor
>>> Daniel Gustafsson wrote:
>>> 
>>>> 
>>>> 
>>>> I am interested in extracting Dosfs in Rtems 4.6.1 to a separate
>>>> module that shall work stand-alone with a commandpromt. The module
>>>> should use a block based ram driver like a simulated disk. Before I
>>>> start I would like to ask if somebody has done the same thing or
>>>> knows any good approaches? The main questions I would like to have
>>>> an answer to is the following:
>>>> 
>>>> 1. What does the file structure of dosfs look like? Which files are
>>>> necessary for a stand-alone module? Which files are connected to
>>>> the different layers (driver, upper interface etc.) of the file
>>>> system? 
>>>> 
>>>> 2. Where should I start? Any tips is greatly accepted?
>>>> 
>>>> 3. Can somebody tell me about any constraints or limitations of
>>>> the fs (max partition size etc.)? 
>>>> 
>>>> 4. Does anyone know the footprint of dosfs in RAM during runtime?
>>>> 
>>>> Best Regards
>>>> Daniel Gustavsson