From: Jim Brain (brain_at_jbrain.com)
Date: 2007-12-24 21:51:14
David Wood wrote:
> I'm not attempting to be a featurist, but I see no reason why we shouldnt
> use a more real FAT filesystem. Compatibility is always a goal, but if we
> change the filesystem even in the slightest bit, we lose compatibility with
> programs that directly read and write sectors.
>
I think, in today's environment, one should have many choices. I
believe Ruud's goal is this as well. I vote for it.
As such, FAT should be high on the list. It's a brain-dead format, so
it should be easy to implement (what am I saying, it IS easy, even I did
it). A FAT-variant that is more CBM-like is also a possibility.
The SW principals on this project should quickly come up with a module
approach for FS code.
Then, one should use IDE partition tables to denote the partitions,
using 0xf8 (unused, as far as I can tell) as the notation for CBM-FS.
Then, using the Linux/*BSD superblock approach, put the specific variant
in the superblock, along with other interesting information (name,
etc.). Use a major/minor approach, and allow the superblock to grow (if
Linux/*BSD allow that , if not, don't bother)
FS-types should include:
1541/1551,2031,2040/3040/4040, using the same major # and minor numbers
to denote variants
8050,8250,SFD, same here, only worry about per disk stuff, not per dual
drive (you cna handle dual drive semantics in DOS)
1571
1581
FD
CMD-HD Native
CMD-HD Foreign
D90XX (sure, the likelihood it will be implemented is small, but let
someone with an itch to scratch have the ID, use the lower byte for the
variants (9060/9090)
IDE64 (assuming it needs a special major number, or does not already
have one)
I think A major number should be devoted to experimental FS, like DebFS
and the like. Then, if they grow into something useful, move them int
their own major.
A little thought in the beginning (module approach, superblocks,
partitions, major/minors for FS types) I think will allow everyone to do
as they wish.
Jim
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.