> --
> You received this message because you are subscribed to the Google Groups "minix3" group.
> To post to this group, send email to min...@googlegroups.com.
> To unsubscribe from this group, send email to minix3+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/minix3?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups "minix3" group.
To post to this group, send email to min...@googlegroups.com.
To unsubscribe from this group, send email to minix3+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/minix3?hl=en.
You are right. Get the FAT specification from Microsoft and
implement it based in a MINIX specific way (system calls, coding
guidelines etc).
A good place to get started is http://wiki.osdev.org/FAT for
example.
--
Juho Hiltunen
jhil...@ulapland.fi
+358 (0)407730352
I believe having FAT32 working is only a matter of having people
dedicating time to polish the code. I have raw code for a FAT file
system server, but
- I saw nobody interested by testing the code as it stands;
- the internals of MINIX evolve too quickly so I cannot stand up;
- I was advised to make sure the code work with GCC rather than ACK,
but I am not able to run a stable version of MINIX based on GCC on my
limited hardware base and within my limited time allocation;
- I have a couple of decisions in stand by, basically about memory
allocation: I wrote the code with the idea to use fixed-memory
allocation scheme as used historically in MINIX, but I am unsure if this
is the way to go in the future (where is going Minix anyway?)
> Additionally I think that FAT32 is a relatively simple filesystem so it's
> also an excellent candidate for a learning experience.
On the other hand, FAT is different by several key features (no unique
central index references like inodes are, misalignment of blocks wrt the
whole file system which affects the way caching is handled) so a fair
part of the way FAT differs from MFS is not reusable for others FS.
Antoine
In my experience, writing a file system server, particularly one which
is served by real-hardware drivers, unlike hgfs or procfs, is highly
based on the existing code in MFS (and now ext2fs, since it followed the
same path.)
The amount of code to write is MUCH bigger than with porting a package;
for FAT, I believe I wrote from scratch about 20% (of 4400 lines), about
20% have been lifted from other packages, I rewrote 50% of existing MFS
code and only 10% are unchanged; I certainly went too far in rewriting,
but I believe it would be difficult to go below 20/20/30/30 for FAT.
Evgeniy might comment on for its part, I believe he was able to reuse a
lot more of code from MFS unchanged because ext2fs is much more alike
MFS (cf. my previous post, which will appear later in the thread);
OTOH for hgfs I think David wrote far more code from scratch.
Antoine
--
You received this message because you are subscribed to the Google Groups "minix3" group.
To post to this group, send email to min...@googlegroups.com.
To unsubscribe from this group, send email to minix3+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/minix3?hl=en.
> --
> You received this message because you are subscribed to the Google Groups "minix3" group.
> To post to this group, send email to min...@googlegroups.com.
> To unsubscribe from this group, send email to minix3+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/minix3?hl=en.
>
>
--
Evgeniy Ivanov