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.